AD-A1QQ  318 

UNCLASSIFIED 


JET  PROPULSION  LAB  PASADENA  CA 

AUTONOMOUS  SPACECRAFT  MAINTENANCE  STUDY  GROUP. tU) 

FEB  81  M  H  MARSHALL ►  G  D  LOW  NAS7-100 

JPL-PUB-80-88  AFOSR-TR-81-0518 


DUO  file  copy 


SfOSR.TR-  8  1-0518 


r— f 


Vsk^’ 


Final  Report  of  the  Autonomous 
Spacecraft  Maintenance  Study  Group 

Michael  H.  Marshall 
G.  David  Low 


February  1,  1981 


Prepared  for 

The  Air  Force  Office  of  Scientific  Research 
Through  an  agreement  with 
National  Aeronautics  and  Space  Administration 
by 

Jet  Propulsion  Laboratory 

California  Institute  of  Technology 
Pasadena,  California 


\  APProv©a  for  puMie  release ; 

distribution  uallaitad. 

v  ft  i  6  1  2  1^6 


UNCLASSlIiKU 


SECURITY  CLASSIFICATION  OF  THIS  RAGE  (IVh«in  Data  Enlrrrd) 


EPORT  DOCUMENTATION  PAGE 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


4.  TITLE  (and  Subtitle) 

AUTONOMOUS  SPACECRAFT  MAINTENANCE  STUDY 

GROUP 

5  type  of  report  ^  period  covered 

— ^  FINAL 

6.  PERFORMING  ORG.  REPORT  NUMBER 

JIM.  Rfl-RR 

7.  AU  T HORfaj) 

8.  CONTRACT  OR  GRANT  NUMBER(«; 

M * ' H.- MARSHALL 

G.  DAVID  LOW 

1  . 

NAS  7- 1 00 

♦.  l»eRTORWtW»-ORG’AWrr ATION  NAME  AND  ADDRESS 

Jet  Propulsion  Laboratory 

California  Institute  of  Technology 

Pasadena,  California 

10.  PROGRAM  ELEMENT,  PROJECT.  TASK 
AREA  &  WORK  UNIT  NUMBERS 

61 102 F  RD-182 

11.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

AF0SR/X0T 

1 1/ 

12  REPORT  DATE 

/  Feb  l..  .1981 

BLDG  410 

BOLLING  AFB ,  DC  20332 

U.  NUMBER  OF  PAGES 

40 

14.  MONITORING  AGENCY  NAME  4  AOORESS(ff  diKctcnt  (raw  Controlling  Ollier) 

National  Aeronautics  and  Space  Administration 
Headquarters 

Washington,  DC 

IS.  SECURITY  CLASS,  (of  this  report) 

UNCLASSIFIED 

15«.  DECL  ASSIF| CATION  DOWNGRADING 
SCHEDULE 

16.  DISTRIBUTION  STATEMENT  (of  this  Report) 

Approve  for  public  release;  distribution 

uni imi t  ec 

•  "j  <  —  ‘ 

17.  DISTRIBUTION  STATEMENT  (of  (ho  abstract  onlered  in  Block  20. 

different  from  Report) 

19.  KEY  WORDS  (Continue  on  reverse  side  if  necessary  and  identify  by  block  number) 

spacecraft  system  technology 
f au  1 1- to  1 e ran t  computing 
autonomous  spacecraft  maintenance 


20.  ABSTRACT  (Continue  on  reverse  side  If  necessary  and  Identify  by  block  number) 

This  report  outlines  a  plan  to  incorporate  autonomous  spacecraft  maintenance 
(ASM)  capabilities  into  Air  Force  spacecraft  by  1989.  These  capabilities 
include  the  successful  operation  of  the  spacecraft  without  ground-operator 
intervention  for  extended  periods  of  time.  Autonmous  maintenance  requires 
extensive  use  of  onboard  fault  detection,  isolation,  and  recovery  mechanisms 
integrated  into  the  spacecraft  within  a  hierarchical  architecture.  These 
mechanisms,  along  with  a  f  au  1  t-f  o  1  e  ran  t  da  i  a  processing  system  (Coni,.  1 


security  classification  of  this  page  'in,m  r>» r»  Entrrrdt 


I  JAN*73  1  473  EDITION  OF  I  NOV  65  IS  OBSOLETE 


SECURITY  CLASSIFICATION  OF  THIS  PAGEOHion  Data  Entarad) 


(including  a  nonvolatile  backup  memory)  and  an  aptdnq&ous Jn^vigj  ipn  capabilit; 
qj*e  needed  to  replace  the  routine  servicing  that  is  presently  performed  by 
the  ground  system. 

As  part  of  this  study,  the  state-of-the-art  fault-handling  capabilities  of 
various  spacecraft  and  computers  are  described,  and  a  set  oi  conceptual  design 
requirements  needed  to  achieve  ASM  are  established.  From  these  two  inputs, 
an  implementation  plan  describing  near-term  technology  development  needed  for 
an  ADM- proof-of-concept  demonstration  by  1985,  and  a  research  agenda  addressini 
long-range  academic  research  for  an  advanced  ASM  system  of  the  1990's,  are 
establ ished. 


UNChASS  I  F  1  KI) 


SECURITY  CLASSIFICATION  OF  THIS  PAGE(H7i»rt  Data  Entarad) 


JPL  PUBLICATION  80-88 


Final  Report  of  the  Autonomous 
Spacecraft  Maintenance  Study  Group 

Michael  H.  Marshall 
G.  David  Low 


Approved: 


C.  Carl,  Study  Manager 


/  N.  Bryden,  Defense  Technology 
*nd  Program  Development 
Office  Manager 


February  1,  1981 


A-' 


Prepared  for 

The  Air  Force  Office  of  Scientific  Research 
Through  an  agreement  with 
National  Aeronautics  and  Space  Administration 

by 

Jet  Propulsion  Laboratory  - 

California  Institute  of  Technology*11*  FORCE  office  cjf  scientific  RESEARCH  /afsci 
Pasadena,  California  NOTICE  OF  TRANSMITTAL  TO  DDC 

IhU  twbnloal  report  Has  boon  reviewed  and  is 
approved  for  public  release  IAW  AFR  190-ia  (7bJ, 
Distribution  la  uoliaiteti.  ^  1  J 

A.  D.  BLOSS  ^ 

Xaobalual  laf orwetloc^ (kff  leer 


p:  1 

Av 

ll-ict 

8. 
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Preface 


As  currently  designed  and  flown,  spacecraf  t  need  considerable  maintenance  to  perform 
then  missions  Mission  readiness  is  jeopardized,  however,  because  t he  ground  support  that 
provides  the  maintenance  is  vulnerable  to  both  hostile  action  and  operator  errors.  To 
address  this,  the  Jet  Propulsion  Laboratory  (JPL).  California  Institute  of  Technology,  was 
commissioned  in  March  I UhO  by  the  Air  Force  Office  of  Scientific  Research  to  lead  a 
study  of  autonomous  spacecraft  maintenance  (ASM).  ASM  is  a  spacecraft  design  ttial 
tolerates  hardware  and  software  fa'lures  and  design  faults,  while  requiring  minimum 
ground  contact  to  perform  the  mission.  The  study  group,  composed  of  experts  from 
industry,  academia,  and  NASA,  was  to  identify  critical  issues  related  to  ASM  technology 
development  and  detail  the  infusion  of  this  technology  into  future  Air  Force  spacecraft 
systems  To  facilitate  this,  three  subgroups  were  formed:  the  Spacecraft  System  Tech¬ 
nology  Working  Group,  composed  of  spacecraft  system  specialists  from  various  spacecraft 
suppliers,  the  Fault -Tolerant  Technology  Working  Group,  composed  of  specialists  in 
fault-tolerant  compute!  technology  from  academic  and  independent  research  institutions: 
and  the  .Academic  Assessment  Committee. comprised  of  leading  researchers  f  rom  academic 
and  independent  research  institutions. 

These  groups  weie  brought  together  in  a  series  of  three  workshops  held  at  JPL  in  May . 
July  ,  and  August  lo.xo.  under  the  guidance  of  the  Study  Planning  Committee.  The 
spacecraft  systems  .,nd  fault -tolerant  working  group  members  presented  their  organiza¬ 
tions'  cuirent  capabilities  m  spacecraft  and  fault-tolerant  computers,  respectively  ,  from 
which  a  stete-ol  the-.n 1  technical  data  base  was  established.  A  set  of  conceptual  design 
requirements  was  then  developed,  detailing  what  an  ASM  spacecraft  must  do.  Thus, 
knowing  on  one  h  ind  t’w  capabilities  of  current  spacecraft,  and.  on  the  other,  the  require¬ 
ments  lor  ASM.  the  working  gioups  began  a  search  for  the  optimum  plan  for  the  integra¬ 
tion  of  ASM  into  spaceciaft. 

The  mejoi  ptoduci  •:  the  .Spaceciaft  System  Technology  Working  Group  was  the 
Implementation  Plan,  which  details  the  group's  recommended  approach  for  incorporating 
ASM  capabilities  into  operational  spacecraft  by  Idgo,  The  Fault-Tolerant  Technology 
Woikmg  Group  and  the  Academic  Assessment  Committee  togethei  established  the 
Researc!  Agenda,  which  outlines  basic  research  activities  required  to  till  technological 
gaps. 


If  i>  iioped  dial  the  mat'tial  piesen'ed  here  will  provide  guidance  for  file  evolution 
ol  ftituie  spacecraft  systems  The  study  paiticipants  believe  that  the  interaction  between 
Ihe  working  gioups  has  been  synergistic,  and  has  contributed  to  an  increased  awareness 
of  potential  technology  capabilities. 
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Abstract 


This  report  outlines  a  plan  to  incorporate  autonomous  spacecraft  maintenance  (ASM) 
capabilities  into  Air  Force  spacecraft  by  1989.  These  capabilities  include  the  successful 
operation  of  the  spacecraft  without  ground-operator  intervention  lot  extended  periods  of 
time.  Autonomous  maintenance  requires  extensive  use  of  onboard  fault  detection,  isola¬ 
tion.  and  recovery  mechanisms  integrated  into  the  spacecraft  within  a  hierarchical  archi¬ 
tecture  These  mechanisms,  along  with  a  fault-tolerant  data  processing  system  (including  a 
nonvolatile  backup  memory)  and  an  autonomous  navigation  capability,  are  needed  to 
replace  the  routine  servicing  that  is  presently  performed  by  the  ground  system. 

As  part  of  this  study,  the  state-of-the-art  fault-handling  capabilities  of  various  space¬ 
craft  and  computers  are  described,  and  a  set  of  conceptual  design  requirements  needed 
to  achieve  ASM  are  established.  From  these  two  inputs,  an  implementation  plan  describ¬ 
ing  near-term  technology  development  needed  for  an  ASM  proof-of-coneept  demonstra¬ 
tion  by  1985,  and  a  research  agenda  addressing  long-range  academic  research  for  an 
advanced  ASM  system  of  the  1990s.  are  established. 
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Executive  Summary 


I.  Introduction 

Spaeeeratt  are  presently  designed  to  interact  with  the 
giound-eontrol  operations  eentei  tor  routine  tnaintenanee  and 
tot  fault  diagnosis  and  reconfiguration  in  the  event  of  onboatd 
piohlems.  During  periods  ot  conflict,  hovvevet.  the  conttol 
operations  eentei  is  vulnerable  to  hostile  action  In  continue 
opeiation  during  these  periods,  spacecraft  must  he  capable  of 
autonomously  performing  predetermined  ground  functions; this 
is  accomplished  by  autonomon*  spaceciall  maintenance 
l  \SM  l  ASM  maintains  the  spaceciatt  in  a  state  ol  readiness  bv 
pi"Vtding  spaceciatt  designs  tli.it  requite  no  gioimd  contact 
tiiiei action  lot  otihoaid  detection,  isolation,  and  i.voveiy 
hom  laulls  01  loi  routine  operations  such  as  power  manage¬ 
ment 

lire  study  gtottp  was  cotutni- stoned  to  deteimuie  a  vv.iv  to 
mcoipoiate  \SM  into  spaceciatt  to  do  this,  they  liisl  made 
staie-ot-the-.n i  teehnologv  assessment  o|  euneni  spaeeciatt 
sv stems,  ami  then  deteimtned  some  geneial  lequnemeiiis  toi 
an  ASM  spaceciatt  horn  this,  tltev  developed  the  l tuple 
mentation  Plan  that  leads  to  .'he  incorporation  o)  ASM  into 
opei.ilion.il  spaceciatt  *»v  Included  in  this  was  an 

identitic.iliou  o|  the  needed  technologies  to  till  immediate 
gaps,  lo  address  longei-ieiiti  teehnologv  issues  tot  use  m  a 
soeond-eene'ation  ASM  sp.ieect.il!  o|  the  l0,,Us.  the  study 
gioitp  al-.o  dm-'loped  the  Rese.uch  Vacnd.i. 

II.  State-of-the-Art  Technology 

I  he  memheis  o|  the  vvoiking  comps  presented  examples  ol 
ament  spaeeciatt  and  l.iulltoleianl  computet  systems. 


deseiihmg  then  lault  -handling  chaiacteiistics.  I  samples  ot  the 
spaceciatt  piesenled  vveie.  H.TSAK  OM  and  I.IAS.A!  (coin- 
municationsl.  (iloh.il  Positioning  Sy stent  ( navigation I.  Detense 
Meteoiologtc.il  Satellite  Ptogum  (meteoiologicalt.  NASA's 
Multimission  Modular  Spaceciatt  I imiltiimssion |.  and  Voy.iget 
(planetaiv  exploration t  Although  each  of  these  spaceciall 
peitotm  some  functions  autonomously .  none  is  capable  ot 
lulls  autonomous  opeiation.  mainly  because  (his  capubrlm 
has  nevei  been  icquued  01  speulted  I  he  lauh-tolei.int 
compute! s  described  vveie  I  atilt- 1 oleiant  Spacebome  (  out- 
putei  and  lhiildmg  Block  fault- 1  oleiant  Computet  (space- 
b.unel.  (  . 1 1 1 1 up .  Cm*,  and  (  uup  (comineici.il I.  and  Soitwaie 
Implemented  I  unit -  foieianee  and  l  ault- 1  oleiant  Multipio- 
cessot  t cointneici.il  aviation).  Ot  the  laulMolei.ini  computeis 
piesenled.  n .'tie  is  opeiat tonal  v el .  and  only  the  I  .mil -1  oleiant 
Spucchoinc  Computet  and  Building  Block  fault- 1  oleiant 
(  ontputei  will  be  applicable  to  spaceci.ift  sv  stent'  Die  others. 
Irowevei.  provided  es.mtples  ot  design  nietltodologtes  and 
techniques  that  may  he  applicable  to  spaeehome  computeis 

I  ach  ol  the  spaceciatt  that  was  piesenled  teejuued  itttei.k- 
(ton  u ith  the  gtoum)  system  lot  1101111..I  opet.Utons  manage- 
ment.  as  well  as  lault  diagnosis  and  tecovery  ihts  intctaction 
was  needed  lot  siieh  things  as  povvei  man  igement .  housekeep¬ 
ing.  navigation  collections,  and  attv  abnotmahltes  that 
occiined  Having  the  spaeeciatt  icly  on  the  conttol  opeiatlons 
eentei  makes  the  overall  space  system  as  vulnerable  as  i he 
eonliol  opeiaiions  eentei  It  also  cieates  a  long  "down  time" 
wlteievei  a  lault  ocvuis.  because  the  lault  must  be  diagnosed 
and  leeonliguiation  eontmands  must  Ire  developed  bv  the 
eontiol  i  peiations  eentei  t  his  vulnerability  and  down  time 
can  be  reduced  bv  shilling  the  management  of  routine 


operations  and  fault  handling  from  the  gtound  to  the 
spacecraft  ti.e..  the  spaceciali  perlonns  then)  autonomously). 

Thus,  the  need  lot  ASM  is  iccogm/ed;  fmthetmoie.  the 
study  group  believes  that  the  technology  available  in  todav's 
spacecraft  systems  is  a  good  foundation  liom  which  to 
proceed  to  ASM. 

III.  The  ASM-Enhanced  System 

The  Impact  of  ASM  on  future  An  Foice  spacecraft  is  based 
upon  an  analysis  of  the  cunent  system’s  ability  to  meet  the 
candidate  design  requirements  humiliated  by  the  study  gioup. 
In  summary,  these  ASM  conceptual  design  lequiiemetits  are 

(I)  The  ASM  spacecraft  shall  operate  without  ground 
intervention  for  tip  to  <*U  days  with  no  peilorniauce 
degradation,  and  up  to  (*  months  with  rlegtaded.  but 
acceptable,  performance.  (The  actual  periods  of  auto¬ 
nomy  may  van  with  dillerent  mission  applications, 
however,  the  participants  felt  that  these  were  worth¬ 
while  goals  for  this  study  ! 

(21  ASM  shall  not  reduce  the  spacecrafts'  performance  01 
design  lifetime. 

(e!  The  ground  segment  shall  always  he  able  to  oveinde 
ASM  actions  and  interrogate  the  spacecraft  foi  fault- 
management  data  (audit  trails!. 

Satisfying  these  design  requiiements  implies  the  movement 
ot  routine  maintenance  and  operations  liom  the  giouiid 
segment  to  the  space  segment  The  contiol  opciations  center 
will  assume  a  supervisor  role,  potentially  less  complex,  while 
the  space  segment  will  become  moie  complex.  The  lesulting 
benefits  of  ASM  would  then  include.  ( I  ( reduced  system 
vulnei abr  1  it \  because  the  spacecraft  is  no  longei  dependent 
upon  the  control  operations  center  and  (2)tastci  recoveiy 
tiorn  failures  (seconds  instead  of  horns  01  possibly  days), 

I  he  impact  of  ASM  on  spacecraf  t  design  is  expected  to  he 
evolutionary  Iiaditional  subsystems  aie  expected  to  be 
augmented  by  rwo  new  subsystems  a  taiilt-toleiant  data 
processing  subsystem  with  nonvolalile  back-up  ineinoiy.  and 
an  autonomous  navigation  subsystem. 

I  he  system  aichitectme  is  expected  to  possess  a’Tavered" 
laull  piotection  scheme,  enabling  fault  coiilammeiil  at  the 
lowest  possible  level  to  mimmi/e  subsystem  mlei dependencies. 
In  tins  scheme,  individual  subsv stems,  undei  system  contiol. 
will  be  lOipiiied  to  diagnose  local  lailuies  ,md  take  collective 
action  The  system  will  be  icquned  to  diagnose  and  collect 
ambiguous  lailuies  within  the  subsystem  mlei  laces  and  \SM 
mechanisms  themselves,  as  well  as  to  nidicioiislv  allocate  the 
sv  stem  lesomees 


IV.  Implementation  Plan 

The  Implementation  Plan  focuses  on  neai-lerm  industrial 
technology  development  and.  most  importantly,  the  eailtest 
possible  system-level  proof-of-concept  demonstration  (  1  5  ) 

to  support  a  |‘MW  launch.  The  plan  stresses  delivery  of 
“pioduet"  in  a  steady  stieam  from  subsystems  to  a  complete 
system  for  the  System  Program  Offices'  consideration  and 
mtioduciioii  into  llight  programs. 

As  shown  in  Tig.  I.  the  Implementation  Plan  consists  ol 
tom  major  tasks.  These  are:  ( I  )  redesign  of  existing  sttbsvs- 
tems  to  eliaraeteri/.e  and  demonstrate  ASM  capabilities: 
(2)  design,  develop,  and  lest  an  ASM  system  demonstration 
breadboard  to  show  that  ASM  is  a  viable  concept:  (2)  pcrfoiui 
applications  research  required  to  develop  an  autonomous 
navigation  capability  and  a  fault-tolerant  data  processing 
capability  to  till  existing  technology  gaps;  and  (4)  baste 
reseaieh  needed  to  develop  a  second-generation  ASM  sv  stem 
tot  the  ll>‘*()s  A  section  ol  tins  report.  “Research  Agenda.” 
elaborates  upon  Task  4. 

A  budgetaiy  resomee  estimate  for  the  proposed  ASM 
program  is  S.’h.4M  (TYKO  dollars!  over  five  years.  Fot  several 
reasons,  this  figure  should  he  considered  only  an  estimate. 
First,  the  cost  of  developing  the  new  technology  is  not  well 
known.  Second,  a  specific  mission  application  has  not  been 
assumed,  and  so  candidate  spacecraft  could  not  be  assumed, 
f  inally.  subs/au/Mling  data  was  not  provided  by  the  industrial 
participants.  Tui  these  reasons,  a  moie  definitive  cost  studv 
should  be  petfoimed  in  the  initial  phase  of  the  activity 

V.  Research  Agenda 

The  Reseaieh  Agenda  proposes  basic  icseareh  that  is  a 
syneigistic  pan  ol  the  ASM  ptogiam.  Future  ASM  develop¬ 
ment  activities  aie  focused  on  live  .neas  (  I )  veiy -large-scale 
integration  (NlSIl  technology,  which  includes  sell-testing 
VI  SI  and  on-chip  ledundaney  :  ( 2 1  system  .uchitectuie.  which 
addiesses  spaceciali  oig.ini/alional  issues,  aiehiteetm.il  devel- 
opmenis.  and  advanced  system  studies,  ( 2)  sottvvaic  t .ml t 
loletanee.  consisting  ot  sy  stem  partitioning  and  into  lace 
vie t in i t h *n .  sell-checking  Ihglii  soltvvaie.  and  lault  toleiaiil 
soltwjie:  (4)  modeling  and  analysis,  composed  ol  experi¬ 
mental  testing,  statistical  modeling,  and  lunelional  desenp- 
tion.  modeling,  and  veiilieation .  and  (x)  suppoitmg  develop¬ 
ments  needed  to  loiniulate  an  ASM  data  base,  and  to  build  an 
ASM  qv.ieeeialt  laboiatoiy. 

VI.  Conclusions  and  Recommendations 

Hie  following  conclusions  and  lecommendation  aie  those 
ot  the  study  gioup  paitieipants.  icsulting  liom  analysis  of  the 
maleiuil  developed  dining  the  woikshops. 
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A.  Conclusions 

(  I  )  \SM.  tully  implemented  would  leduco  space  system 
vulnerability  h\  eliminating  spacecialt  dependence  tin 
the  control  operations  cewci  I'M  up  in  (>  months  at  a 

time 

i  ?l  The  ASM  capability  need  not  imp. ,se  opciation.il  om- 
stiaints  .>11  the  s\ ^,1  «.-i n  user.  i:  unist  ho  ■'(ranspaietil” 
i<>  i ho  unoi  dining  noimai  svstem  operations 

I.')  ASM  would  lequne  a  change  in  the  conduct  of  opera¬ 
tions  and  conliol.  It.'in  dependence  on  a  man  in  the 
loop  to  dependence  >>n  machine;,  tor  fault  handling 
and  routine  maintenance  operations. 

(4)  ASM  would  increase  the  spaceciafi  complexity 
therefore.  new  methods  I'm  spec 1 1 >  ing .  testing,  and 
validating  ASM-onhanced  spacecraft  ate  needed. 

(?)  A  more  effective  means  of  transieiring  technology 
Iiotn  reseaicli  io  applications  programs  would  he 
rccjuii cd  so  that  spacecialt  piohlems  could  he  solved 
with  the  latest  available  technology. 

(<>)  New  technology  developments  would  lv  tequiied: 
needed  aie  a  higldv  lehahle  lanlt-toletani  data  pro 
cessing  system  with  nonvolatile  backup  memory  to 
enable  autonomous  maintenance,  and  an  .-utonomoiis 


navigation  capability  to  enable  Independence  of 
routine  ground  operations. 

(7)  ASM  would  he  a  phased  piogram;  spacecraft  would 
not  instantly  become  totally  autonomous.  The  pace 
of  ASM  development  would  depend  on  the  resources, 
technology,  and  chosen  progtam  applications  that  are 
available.  A  strong  corporate  commitment  to  ASM  bv 
the  Air  Force,  along  w  ith  a  willingness  by  industry  to 
assimilate  ASM.  would  oe  required  to  make  ASM 
successful. 

(HI  Conlidence  in  ASM  must  be  instilled  by  aeatioii  nt 
a  systematic  modeling,  analysis,  and  demonstiaii"ii 
piogiam. 

(4)  Although  considerable  technology  developments  ate 
necessary,  no  requiiemcnts  foi  technology  bieak- 
thiouglis  have  been  identified, 

(10)  In  the  opinion  of  (he  study  giotip.  ASM  is  a  viable 
concept. 

B.  Recommendation 

I'he  study  gioup  lecommemls  that  the  ASM  icseaich  and 
technology  development  activities,  as  outlined  in  the  Imple¬ 
mentation  Plan  and  Research  Agenda  sections  oi  tills  lepoii. 
be  initiated  a>  soon  as  possible.  Tins  would  enable  the  earliest 
possible  spacecialt  system-level  proofot -concept  denionstra 
non  of  ASM. 
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Introduction 


Currently,  when  certain  critical  failure  slates  are  detected, 
spacecraft  usually  enter  a  "safe-hold"  mode;  in  this  mode, 
operations  are  suspended  and  ground  intervention  in  the  form 
of  reconfiguration  commands  is  required  to  restore  normal 
opeiations.  Spacecraft  are  also  not  presently  designed  to  auton¬ 
omously  recover  from  design  faults,  software  failures,  or 
changing  environmental  conditions. 

Autonomous  spacecraft  maintenance  is  characterized  by: 

(1)  Spacecraft  design  that  tolerates  hardware  and  software 
failures  and  design  faults. 

(2)  Spacecraft  design  that  requires  tor  extended  periods 
of  time  virtually  no  ground  contact/interaction  for 
onboard  detection,  isolation,  and  recovery  of  faults,  or 
routine  maintenance  functions. 

For  the  most  part,  such  capabilities  have  been  beyond  the 
state  of  the  art  of  spacecraft  systems.  This  study  group  has 
been  commissioned  by  the  Air  Force  to  address  these  issues, 
and  to  detail  a  plan  leading  to  the  incorporation  of  ASM  into 
operational  spacecraft  by  1‘)K‘). 


I.  Current  Space  Systems 

The  space  system  is  composed  of  the  space  segment  and 
the  ground  segment,  as  illustrated  in  Fig.  2.  For  this  study,  the 


space  segment  consists  of  only  the  spacecraft,  while  the 
ground  segment  consists  of  three  separate  entities:  data 
processing  stations,  communications  centers,  and  a  control 
operations  center.  The  data  processing  stations  and  the  com¬ 
munications  centers  may  be  numerous  and  are  payload-data 
users  only,  whereas  the  contiol, operations  centei  is  nonre- 
dundant  and  is  responsible  for  the  overall  management  of  the 
spacecraft. 

II.  Definition  of  the  Problem 

It  can  be  seen  that  the  loss  of  any  single  data  processing 
station  or  communications  center  will  not  jeopardize  the  space 
segment ;  on  the  other  hand,  the  loss  of  the  control  operations 
center  may  eventually  render  the  entire  space  system  ineffec¬ 
tive.  The  dependence  of  the  spacecraft  on  the  contiol  opera- 
lions  centei  and  the  vulnerability  of  the  center  to  hostile 
action  and  operator  error  are  the  concerns  ot  this  siudy 

III.  Scope  of  the  Study 

Spacecraft  autonomy  involves  several  elements:  autono¬ 
mous  spaeeciall  maintenance,  autonomous  mission  sequencing 
and  control,  autonomous  navigation,  ami  autonomous  pav  load 
data  processing.  lo  have  a  completely  autonomous  spaceciuft. 
all  of  these  elements  would  have  to  be  included  Tins  .study  , 
howevei,  was  to  addiess  onlv  the  spacecraft  maintenance 
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(spacecraft  "health  and  welfare")  aspect  of  autonomy.  This 
includes  the  maintenance  of  satisfactory  system  performance 
in  the  presence  of  internal  faults,  and  the  movement  of  routine 
maintenance  functions  from  the  around  station  to  the  space¬ 
craft.  It  is  assumed  that  other  studies  will  address  the  other 
elements  of  autonomy.  With  this  assumption  in  mind,  the 
following  topics  were  addressed: 

( 1 )  The  state  of  the  art  of  ASM  in  spacecraft  design. 

(2)  An  ASM  design  methodology. 


(3)  An  implementation  plan  leading  to  the  demonstration 
of  ASM  concepts. 

(4)  Research  areas  applicable  to  ASM. 

(5)  A  basic  reseat ch  agenda  that  supports  the  development 
of  ASM. 

These  topics  and  their  key  tesults  are  discussed  in  the  sections 
that  follow. 


ground  segment 


Fig.  2.  The  space  system 
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State-of-the-Art  Technology 


The  members  of  the  Spacecraft  System  Technology  and 
Fault-Tolerant  Technology  Working  Groups  presented  descrip¬ 
tions  of  the  fault-handling  characteristics  of  existing  spacecraft 
and  fault-tolerant  computer  systems.  These  were  representa¬ 
tive  id  successful  s\ stems  designed  to  operate  within  specific 
environments'  the  spacecraft  systems  for  the  space  environ- 
nieni.  and  the  computer  systems  (to  date)  within  laboratory 
environments.  In  this  section,  a  summary  oi  the  current 
capabilities  o!  the  spacecraft  and  tault-toleianl  compute) 
systems  is  given,  toll  owed  by  ail  assessment  ol  their  relevance 
to  ASM. 

I.  Spacecraft 

An  force  satellites  can  be  categorized  into  four  mission 
classes,  communications,  navigation  meteoiologic.il.  and 
surveillance.  During  I  he  workshops,  satellites  Horn  each  o|  the 
classes  except  surveillance  were  presented.  Because  siiivciII.uk e 
satellites  were  classified,  no  detailed  inhumation  was  solicited 
Additionally,  presentations  were  given  describing  some  ol  the 
planetary  exploration  spacecraft. 

The  members  of  the  Spacecraft  System  Technology  Work¬ 
ing  Group  were  chosen  because  of  their  expertise  in  the 


subject  field  and  because  of  then  affiliated  organization's 
experience  as  a  supplier  ol  Air  Force  spacecraft  for  one  oi 
more  of  the  mission  classes.  Lach  membet  described  examples 
of  current  spacecratt.  explaining  its  design  methodology 
lelatmg  to  fault  handling  Numerous  svsteirr  and  subsy  stems 
were  described  In  the  participants'  (lie  systems  presented  in 
this  section  aie  example'  only,  icpresenting  the  difterem 
mission  classes  li  n  not  being  suggested  that  these  spacecraft 
are  leading  candidates  toi  then  mission  application.  Such  an 
assessment  was  not  a  pan  of  the  study  .  The  fault-handling 
chains tenstics  ol  the  loilowing  spacecraft  will  be  described 

Mission  class  I. sample  spaeecialf 

(  ommunk.iiions  FT  TSATCOM.  1  FASAT 

Navigation  Global  Positioning  System 

Meieoiologie.il  Detense  Meteorologie.il 

Satelhlc  I’logtam 

Multimission  Muitunission  Modtilai 

Spacecraft 

I’l.inetarv  exploiation  Vovagei 
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A.  Example  Spacecraft 

1.  Communications  spacecraft.  FLTSATCOM  is  a  3-axis 
stabilized,  23-channel  communications  satellite.  It  flies  in  a 
geosynchronous  orbit  and  has  a  5-year  design  life.  Four  of 
these  spacecraft  are  operational;  the  first  was  launched  on  Feb¬ 
ruary1),  1978.  Its  fault-handling  characteristics  are  given  in 
Table  1. 


2.  Navigation  spacecraft.  The  Global  Positioning  System 
(GPS)  satellite  is  a  3-axis  stabilized,  semisyncbronous  ( 1 2-hour 
orbit)  navigation  satellite.  It  will  enable  a  user  to  accurately 
determine  his  position,  velocity,  and  time.  When  fully  opera¬ 
tional.  there  will  be  18  satellites  on  orbit.  To  date  six  have 
been  launched,  the  first  on  February  22.  1977.  Each  satellite  is 
designed  for  a  mean  mission  duration  of  5  years;  the  fault¬ 
handling  characteristics  are  given  in  Table  3. 


Table  1.  FLTSATCOM  fault-handling  characteristics 


Hi  ult  -lolt*  run  l 
attribute 


Description 


Reliability  achieved  by  redundant  components 
Cross-strapping 

Onboard 

hardware 

Onboard  sw  itching  to  “safe-hold ”  mode 
Undervoltage  detection  resulting  in  automatic 
load  shed 

Battery  cell  monitor  and  switching 

Command  receiver  toggle 

On  boa  rd 
software 

N'.mc 

Allow  ground  intervention  lor  failure  anahsis 

( Wound 

and  swnchiii).' 

assisted 

Redundancy  management  on  ground 
(hound  override  capability 

L.FASAT  is  a  spin-stabilized  geosynchronous  communi¬ 
cations  satellite  designated  as  a  functional  follow-on  to 
FLTSATCOM,  with  a  design  life  of  10  years.  Four  satellites 
will  he  shuttle-launched  beginning  in  1984.  These  satellites’ 
fault-handling  characteristics  are  given  in  Table  2. 


Table  2.  LEASAT  fault-handling  characteristics 


l.iult-tnleranl 

jttributi- 


Description 


Automatic  transfer  to  rate-hold  mode  in  event  of 
loss  of  sensor 

Automatically  activates  redundant  control 
clectromcs/rtintor  driver  and  motor  in  event 
Onhoa'd  ot  loss  ol  dcspm  control 

hardware  No  single-point  f  tiluTCs  in  tluuslci  operations 

Automatic  fault  detection  and  ground  alerting 
Redundant  elements  to  unit  level 
Receiver  time  out 
Watch  dug  timers 


Onboard 

software 


None 


Allow  ground  intervention  for  failure  analysis 
and  switching 

Redundant  switching  for  battery  charge  rates  and 
battery  reconditioning 
Redundancy  management  on  ground 


Table  3.  Global  Positioning  System  fault- handling  characteristics 


I  ault-tolerant 

.  .  Description 

attribute  r 


Onboard 

hardware 


Onboard 

softwa.e 


(hound 

assisted 


l  ull  redundancy  except  where  impractical 
(e.g..  structure) 

Multiple  redundancy  in  critical  subassemblies 
(e.g..  triply  redundant  atomic  clocks) 
/Automatic  detection  and  isolation 

Electrical  shorts,  attitude  loss  handled  by 
load  shedding 

Jet  runaway  handled  by  watchdog  logic 
Automatic  detection  and  correction  at  unit  level 
for  system  performance  degradation  failures 
Earth  sensor 

Control  Electronics  Assembly  power  supplies 
Masking  of  solar  array  system  performance 
degradation  failures 

Automatic  Sun  reacquisition  from  eclipse 


No  spacecraft  bus  software 


Allow  ground  intervention  tor  failure  analysis  and 
switching 

Redundancy  management  on  ground 
Battery  reconditioning 
Routine  health  and  status  monitoring 
Lphemeris  and  time  update 
Magnetic  momentum  dump 


3.  Meteorological  spacecraft.  Defense  Meteorological  Satel¬ 
lite  Program  (DMSP)  Block  5D  spacecraft  are  3-axis  stabilized 
and  operate  in  a  Sun-synchronous  polar  orbit  at  830  km 
(450  nmi).  The  Block  5D  spacecraft  have  a  2-year  design  life; 
the  first  was  launched  September  1 1 .  1970.  The  fault -handling 
characteristics  of  these  satellites  are  given  in  Table  4. 


4.  Multimission  spacecraft.  The  Multimission  Modular 
Spacecraft  is  3-axis  stabilized  and  can  be  used  for  various 
mission  classes.  It  can  be  used  in  orbital  altitudes  from  low- 
Earth  to  geosynchronous.  The  first  launch  was  February  14. 
1980.  It  has  a  2-year  mission  lifetime,  and  is  capable  of  being 
resupplied  by  the  shuttle.  Its  fault-handling  characteristics 
are  given  in  Table  5. 
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Table  4.  Defense  Meteorological  Satellite  Program 
fault-handling  characteristics 


Table  5.  Multimission  Modular  Spacecraft 
fault-handling  characteristics 


I  ault-tolerant 

,  ,  .  Description 

attribute  * 


fault-tolerant 
at  tribute 


Description 


Hardware  Watchdog  timer  requires  periodic 
response,  protects  against  loss  of  power  and 
clock  or  system  lock-up 
Hardware  testing  of  parity .  illegal  instruct  ions, 
and  memory  addresses  (computer 
self-tests! 

Physical  and  functional  redundance  in 
subsystems 

Hardware  detection  switching  m  power 
subsystem 

Redundant  central  processing  units 

Protective  software  in  powci  \uhs\  stem 
Solar  arras  drive  control 
Battery  state  ot  change,  low  voltage, 
temperature  checks 
Onboard  Load  shedding  in  eve*  t  ot  fault 

software  Software  response  to  e  ors  tested  in  above 

Spare  memory  with  special  software  packages 
to  anticipate  recovery  after  memory  t\alurc\ 
Detectioii/swiiching  m  subsy stems  other  than 
power 

Allow  ground  intervention  f>>i  failure  anafvMs 
and  switching 

(/round  Special  onboard  processor  lest.  memory 

assisted  patterns.  diagnostic  nisirm  ijmij  M'M 

Reprogram  computers 
Data  trend  ana  tv  ms 


Onboard 

hardware 


Onboard 
hardw  jre 


Otiboaid 
no!  tw  aie 


(»found 

assisted 


Block  redundancy 

No  credible  single-point  failures  in  space¬ 
craft  bus 

Computer  failure  detections  (watchdog 
timers)  m  the  attitude  control,  commu¬ 
nications.  and  power  modules;  reconfig¬ 
ures  spacecraft  to  power  sate  Sun-pointing 
mode  using  analog  backup  system 

l  ndervoltage  detection  and  sating 

Batters  sta  tend -charge  calculations 

Computer  self-test 

Spacecraft  oft-pointmg  detection  and  sating 

Telemetry  data  quality  checks 

Internal  validity  checks  for  attitude  deter¬ 
mination  and  control  software 

.Monitor  heaJjh  and  sjjely  of  predetermined 
pay  load  instruments  w  ith  onboard 
N.itme  aw  Molls 

Allow  I'Murtd  mtvrxentum  )«»/  failure  analysis 
and  sw itching 

I’ower  regulator  failure  detection  and 
worrec live  action 

Redundancy  management  on  ground 


Table  6.  Voyager  fault-handling  characteristics 


5.  Planetary  exploration  spacecraft  The  i\u>  3-a\js  stabil¬ 
ized  Voyager  spacecraft. launched  August  20  and  September  5. 

are  designed  to  explore  the  planets  Jupiter  and  Saturn, 
bach  spacecraft  was  designed  for  a  4-year  mission  lifetime, 
although  each  has  enough  expendables  for  possible  extended 
missions.  Table  b  lists  Voyagei’s  fault-handling  characteristics 


I  .uilt-tolcr.mt 
j!  tribute 


Onhord 
h.irdw  ik 


B.  Fault-Handling  Design  Features  Ot  Spacecraft 

Several  observations  van  be  made  front  the  hiuh-handling 
vharaeterMies  ot  tlie  spacecraft  presented.  The  spacecraft 
typically  employ  block  and  functional  redundancy  tor  Inch 
reliability,  as  well  as  watchdog  timers,  cross-strapping,  and  Oni'i'-ml 

sw  it  dime  netwoiks  tor  fault  protection  and  sell  presciv.il  ton 
In  general,  there  are  no  credible  single-point  dilutes.  Hie 
giound-assisted  teatures  include  such  capabilities  asephemetis 
and  time  updates,  trend  analy  sts,  and  mission  recontiguiation 
Redundancy  management  is  done  mostly  on  the  mound,  and 
in  all  cases  th-  mound  lias  an  override  capahihtv 

l  .I'MHItl 

assisted 

Block  redundancy  employs  complete,  identical .  exita 
components  that  can  take  over  in  the  event  of  a  component  _ 


Description 


<  Kertcmpei.itwre  protection  lor  payload 
i  li  n  i  runic  nts 

No  significant  single-point  failures 
Block  .invl  functional  redundant/) 

(  ompu»c’  Nelt-tesi 

Nonvolatile  memory  im  Computer  (  onunand 
Subsystem  am!  Attitude  and  Articulation 
(  ontiol  Subsystem 
I  ndervollJL'C  protection 

bint)  ami  c ode  checks 
Restores  command  link 
Sw  itthes  processors 
Switches  power  elements 
Sw  itches  Suit  star  sensors 
Switches  thrusters /pi limbing 
Reprogrammable 
I  vent  i lining  and  event  counting 
Retry  tor  some  data  transmission  enors 
Block  parity  validation  of  command 
sequences 

Sw  itching  ot  redundant  components  with 
noiKutuslTophic  failure  modes 
Alternate  operating  modes 
I  rend  analysis  and  calibrations 
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failure.  There  are  several  levels  at  which  block  redundancy  can 
be  applied.  In  ascending  order  these  are  the  element,  func¬ 
tional  unit,  functional  string,  subsystem,  and  system  levels. 

Functional  redundancy,  on  the  other  hand,  does  not 
employ  identical  components,  but  instead  performs  nearly  the 
same  functions  using  alternate  system  or  subsystem  configura¬ 
tions.  typically  controlled  from  the  ground.  Functional 
redundancy  has'  an  advantage  met  block  redundancy  in  that  it 
helps  avoid  systematic  design  errors;  however,  it  generally 
does  not  possess  ecjual  performance  capability. 

In  the  event  of  a  failure,  the  operating  philosophy  for  the 
spacecraft  systems  has  been  to  rely  on  ground  interaction  to 
restore  successful  operations.  This  has  given  rise  to  the  safe- 
hold  mode  in  which  the  spacecraft  is  autonomously  switched 
to  a  benign  state  until  ground  interactions  restore  operation. 
The  ground  action  ty  pically  involves  fault  Jelecttoj 1  through 
analysis,  commanded  switching  to  isolate  the  defective  ele¬ 
ment.  and  finally  recovery  procedures  thiough  reconfiguration 
of  available  resources. 

C.  Current  Design  Methodologies 

Methodologies  have  been  defined  to  include  pioctiiement 
management  policies  and  design  development  procedures.  The 
piocmement/nianagement  policies  snucnire  the  development 
ptocess  thiough  the  use  of  formalized  management  tepoits. 
desien  reviews,  and  audits.  Design  development  proceduies 
tele:  to  the  collective  set  of  design  tools  and  test  and  valida¬ 
tion  procedures  that  arc  employed  during  the  development 
process. 

iV.ign  tools  are  employed  to  evaluate  the  adequacy  ol  a 
proposed  design  prioi  to  a  commitment  for  lahiicatiott  Such 
tools  include  simulation,  emulation,  and  reliability  analysts 
techniques  (dclmed  by  Mil  IIUBK  I  T ).  Testing  proceduies 
strive  to  show  that  the  spacecraft  operates  pet  the  design 
intern  they  should  identity  l.iuliv  components  ami  eiiots  m 
mamilaclmmg.  Validation  programs,  on  the  oilier  hand,  stove 
to  insure  the  aeieemeui  ol  the  system  realization  with  the 
system  specification.  This  includes  validation  o|  peilormjnce. 
lehahihty  .  and  environmental  requirements 


II.  Fault-Tolerant  Computing 

An  assessment  ot  the  state  ol  the  art  in  fault-tolerant 
computing  was  undertaken  as  part  ol  the  ASM  study  tor  two 
important  reasons  first .  it  is  ,i  tc,  hnology  that  has  been  undei 
investigation  tor  over  twenty  years,  and  that  has  resulted  m 
the  development  ot  seveial  autonomously  maintained  systems 
(e  g  self-repairing  computer  systems)  Second,  it  appears  that 


onboard  fault-tolerant  computers  will  he  required  to  act  as  the 
automated  lepatrman  for  ASM  spacecraft. 

A  mimhei  of  lault-tolerant  computers  have  already  been 
constructed  and  used.  The  Digest  application  is  in  telephone 
switching  systems  Most  modern  switching  offices  are  autono¬ 
mously  maintained  systems  The  resident  compute!  is  capable 
of  detecting  faults  within  ilselt  and  in  suirotinding  equipment 
replacing  the  faulty  equipment,  and  continuing  noimal  setwise 
(Kef.  1).  Computeis  with  varying  degrees  ol  autonomous 
self-repair  h.ivs'  been  used  m  other  commercial  applnations 
Fxamples  are  the  I’luriluis  Multi)  i  cessoi  tot  sommunis  atiotis 
systems,  and  the  Tandem  Computer  Systems  often  used  lot 
financial  transactions  (Ref.  21.  In  aerospace  sy  stems,  examples 
ol  fault-toleiant  c<  mputing  can  he  tound  in  comtneisi.il 
airplanes,  the  Space  .Shuttle,  jnd  in  the  Saturn  V  guioatise 
computer  ( Ref  ).  Thus  there  exists  a  large  body  ot  design 
expenence  in  the  development  of  lauh-tolerant  it  e  .  autotio 
mously  sell -maintained)  computing  systems  lot  a  vjrtety  <d 
applications. 

Although  two  hrcadhoaid  systems  have  been  constitisted 
and  tested,  and  a  thud  is  under  ucvelopment.  tault-toleiant 
computing  has  not  been  used  on  c.ineni  sp.iceciali  Two  goals 
ot  the  Fault  Tolerant  Technology  Working  Croup  wcie  to 
piovide  a  state-of-the-art  assessment  ot  lault-tolerant  .output 
in g  to  tile  spacecial!  sy  stems  technologists,  and  to  evaluate 
pioblems  and  piospects  foi  employ  ing  tault-toleiant  comput 
mg  m  spaccci.il;  (light  systems.  F.ach  membei  ot  the  w  alking 
group  is  actively  involved  in  the  development  ol  a  state-ot  the- 
ait.  fault-tolerant  computing  system,  and  each  made  piesent.i- 
tions  on  then  sy  stems. 

Seven  lault-tolerant  computing  systems  weie  piesented. 
They  ate  catago-ized  into  three  groups:  ( 1 )  onhoaul  spacecraft 
computers.  ' _  I  avionics  computers,  and  (.?(  cnmmcui.il 
co  mpiiicis. 


A.  Onboard  Spacecraft  Computers 

Two  computer  systems  were  presented,  the  Fault-Tolerant 
Spacchorne  Computer  and  the  Building  Block  Fault-Tolerant 
Computer. 

1.  Fault-Tolerant  Spaceborne  Computer  The  Fault 
Tolerant  Spaceborne  Computet  is  a  general-purpose  computet . 
designed  to  Air  Foice  specifications  of  high  throughput  and  a 
UV,"  probability  of  surviving  (unattended  and  without  degra¬ 
dation  ot  performance)  lor  5  to  7  years.  This  machine  is  cap¬ 
able  ot  sell-reconfiguration  and  resumption  of  computations 
following  internal  component  failures,  power  transients,  and 
radiation  events. 
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The  Fault-Tolerant  Spaeeborne  Computer  is  in  an  advanced 
state  of  development.  A  laboratory  breadboard  has  been 
constructed  and  the  fault-tolerance  features  verified  by  exper¬ 
imental  testing  (e.g. .  insertion  of  faults  and  verifying  proper 
recovery).  The  machine  is  based  on  complementary  metal- 
oxide  semiconducted  silicon  on  sapphire  LSI  technology.  It 
is  not  available  for  flight  use  due  to  an  inability  to  ob'ain 
radiation-hardened  (1000  gate/chip)  integrated  circuits 
(Ref.  4) 

2.  Building  Block  Fault-Tolerant  Computer  The  Building 
Block  Fault-Tolerant  Computer  is  a  fault-tolerant  distributed 
computer  system  architecture.  It  is  aimed  at  spacecraft  systems 
that  employ  a  large  numbei  of  microcomputers  embedded  in 
various  subsystems,  and  is  an  outgrowth  of  the  Unified  Data 
System  architecture  developed  at  JPL  (Ref.  5)  This  architec¬ 
ture  uses  a  small  set  of  standard  building  block  ciicuits  that 
allow  existing  microprocessors  and  memories  to  he  connected 
together  into  fault-tolerant  dislnhuted  computer  systems.  The 
building  blocks  connect  the  central  processing  unit  and  the 
random  access  memory  to  torm  self-checking  computer 
modules  that  can  detect  then  own  internal  faults  dining 
normal  operation.  The  sell-checking  computer  modules 
contain  interlaces  to  a  set  ot  redundant  intercommunication 
buses  md  can  he  connected  into  a  netwoik  in  which  spare 
computers  are  employed  for  fault  iecovei> . 

\  breadboard  ol  the  Building  Block  Fault-Tolerant  Com¬ 
pute  is  currently  being  developed,  and  H  is  expected  that  H 
will  he  completed  and  seiilted  in  imxd.  Flight  availability  wili 
iei|inte  the  subsequent  development  of  two  VLSI  and  I’oui  LSI 
mtegiated  circuits,  and  will  lake  an  additional  two  or  tluee 
years  The  problem  ot  obtaining  ladiaiion  hard  pails  is  com¬ 
mon  to  both  the  Fault  loleranl  Spaeeborne  Computet  and  the 
Building  Bloik  1  anil  1  "leant  Computer  programs. 

B.  Fault-Tolerant  Avionics  Computers 

I  wo  .nioiiik-  luimpuieis  weie  piesenled  fhese  machines 
have  been  developed  In  N  AS  \  toi  control  tutui-  fuel- 
ellkietil  aiKiall  ih.o  will  he  dynamically  unstable.  1  xticmely 
huh  'Oli.ihilny  is  re. i-.ined  siiue  lives  may  depend  on  collect 
."inpu'ei  opeiaiioi  Ilius  a  ich.ihility  "I  o  ooonnoooo  is 
teqmied  toi  even  Liliour  flight  mission  Iliese  avionics 
.  "uipun-is  ate  not  si i : tv  *  1  \  applicable  to  spjceciall  Welch ! 
p-  wer  and  volume  eieatlv  '  ced  w li.it  can  he  supported  by  a 
sp.kiM.ili  Iliey  ate  sis.  designed  to  allow  human  mainlcn- 
aiue  Met  everv  ill-hotii  (light  when  the  plane  is  on  the 
do'll  d  a  eonditiori  not  experienced  In  spacctul! 

Hie  two  avionics  computers  aie  designated  Fault  Tolerant 
Multiprocessoi  and  Sottwaie  Implemented  Fault  Foleranec. 


Both  have  been  developed  as  breadboard  systems  and  are 
currently  under  test.  Though  not  immediately  applicable  to 
spacecraft,  many  of  the  techniques  and  insights  developed  in 
their  design  will  be  applicable  to  long-term  research  into  future 
ASM  systems.  These  machines  are  summarized  below. 

1.  Fault-Tolerant  Multiprocessor.  The  Fault-Tolerant 
Multiprocessor  is  intended  for  use  as  one  of  at  least  two 
central  computers  in  a  redundant  distributed  digital  system 
designed  to  serve  as  a  highly  survivable  avionics  system.  The 
design  is  based  on  independent  processor-cache  memory 
modules  and  common  memory  modules  that  communicate  via 
redundant  serial  buses.  All  information  processing  and  trans¬ 
mission  is  conducted  in  triplicate  so  that  local  voters  in  each 
module  can  correct  errors.  Modules  can  be  retired  and/or 
reassigned  in  any  configuration.  Reconfiguration  is  cunied  out 
routinely  front  second  to  se<  ond  to  search  for  latent  faults  in 
the  voting  and  reconfiguration  elements.  Job  assignments 
are  idl  made  on  a  flouting  Ir'sis.  so  that  any  processoi  tiiad  is 
eligible  to  execute  any  job  step.  The  core  software  in  the 
Fault-Tolerant  Multiprocessor  will  handle  all  fault  detection, 
diagnosis,  and  recovery  in  such  a  wav  that  applications  pro¬ 
grams  do  not  need  to  lie  involved  (Ret',  b). 

2.  Software  Implemented  Fault  Tolerance.  Software  Implc 
mented  Fault  Tolerance  is  an  ultrareliable  computer  for 
critical  aiivralt  control  applications  that  achieves  fault  toler¬ 
ance  by  the  replication  of  tasks  among  processing  units.  The 
main  processing  units  are  off-the-shelf  minicomputers.  Fault 
isolation  is  achieved  by  using  an  individually-buttered,  serial 
data  link  between  each  pioeessor  pair  for  all  processors.  I  irror 
detection  and  analysis  and  system  reconfiguration  are  per- 
toimed  by  sottwaie.  Iterative  lasks  are  redundantly  executed, 
and  the  icsults  ot  each  iteration  are  voted  upon  hcloie  heme 
used.  Thus.  ,niy  single  failure  in  a  processing  unit  or  Inis 
can  he  loleiaied  with  tiiplicatnm  or  qumuipiication  ot  tasks, 
and  subsequent  fatluies  can  he  tuleiated  alter  reconfiguration . 
The  Sottwaie  Implemented  Fault  Tolerance  software  is  highly 
structured  and  is  formally  specified  using  the  SRI-developed 
SP1  (  IAL  language  (Ret.  7) 

C.  Fault-Tolerant  Commercial  Computers 

three  taiili-toleiant  computing  protects  at  Carnegie  Mellon 
I  diversity  weie  piesenled  These  systems  use  DLL  minicom- 
ptileis  and  are  aimed  at  commercial  applications  Though  not 
directly  applicable  to  spacecraft  systems,  some  of  the  insights 
gained  m  then  design  aie  applicable  to  ASM  research.  These 
machines,  designated  C.mnip.  Cm*,  and  C.vmp.  aie  Minimal- 
i zed  below  . 

1  C.mnip,  a  imiltiiniiiiprocessor  C.mnip  is  a  canonical 
multiprocessor  system  with  a  I b  X  lo  crosspoint  switch.  I  'p  to 
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lb  DEC  PDP-11,/40  processors  may  be  connected  to  the 
processor  ports  on  the  switch.  The  lb  memory  ports  provide 
an  address  space  in  shared  memory  of  32  Mbytes.  Any  pro¬ 
cessor  can  access  any  of  the  lb  memory  ports  for  memory 
accesses.  The  entire  set  of  processors  may  communicate  via  an 
interprocessor  bus  that  allows  interprocessor  interrupts  at  one 
of  four  priority  levels,  continuously  broadcasts  a  bO-bit 
nonrepeating  clock  value,  and  allows  any  processor  to  HALT. 
START,  or  CONTINUE  any  other  processor  (Ref.  <S ). 

2.  Cm*,  a  modular  multimicroprocessor.  Cm*  is  a  modular 

multiprocessor  system  based  on  the  LSI-1 1  processor.  Each 
computer  module  is  connected  via  an  interface  to  an  intelli¬ 
gent  cluster  controller.  The  clusters  of  computer  modules  can 
be  interconnected  via  intercluster  buses.  Each  computer  mod¬ 
ule  can  share  memory  with  any  other  computer  module  in  the 
network  through  routing  tables  in  the  cluster  controller 
I  Ret.  M. 

3  C.vmp.  a  voted  multiprocessor.  C.vmp  may  (rest  be 
desciibed  as  a  nmltipiocessor  system  capable  of  lault-tolerant 
opcMtioii.il  consists  of  three  separate  LSI-1  I  microcomputers. 
e.Kii  with  its  own  memory  and  peripherals.  They  may  iuii 
independently  as  three  sepaiate  computers  communicating 
through  parallel  line  units,  or  they  may  be  switched  into  what 
is  termed  voting  mode  under  manual  or  program  control  to 
form  a  triplicated  LSI-1  !.  This  form  of  inplc-modular  redun¬ 
dancy  allows  t he  voted  nmltipiocessor  to  eontinue  operating 
unde:  the  situation  where  any  one  out  ut  three  copies  of  any 
'ripiicaied  element  suffers  a  hard  tailme  (Rei  S) 


III.  State-of-the-Art  Technology  Assessment 

I  'I  ic  «■.  lion  an  a'sessmen'  will  be  made  ot  the  applic 
.!'■  ! .!  >  ■  i  'I.'-  mein  spaced  at  t  and  lault-tolerant  computet 

iuioi.  i .  •  hi  ASM-enlianced  spaced  at  I  In  genet al.  design 
leal, nes  v.  d  need  in  lie  idded  lo  the  spaceciall  to  accomplish 
the  ne .c  Hindi' ars  dictated  hy  ASM  The  procurement 
maii.i'.vment  policies  are  considered  adec|uate  tor  ASM.  bin 
new  design  in.ils.  icli.ibiliiy  techniques.  and  test  validation 
pio^edutes  will  leqimed 

A.  Spacecraft  Technology  Assessment 

V  m  l;  .iied  in  the  in'rodu  >:on.  ASM  consists  ot  space- 
d.if  tc'sieti.  thn  i. ih  i. nc  t.iilmes  and  tliat  icipnie  no  ground 
i  "til  i  i  un'ei.h  :i"ii  l"i  e  Mended  periods  of  lime.  The  toil  ow¬ 
ing  .isses.ment  ot  c.iiieni  technology  is  given  against  these 
al  1  ributes 

I  Design  features  lu  each  ot  I  ho  picseiilatioiis  there  were 
>everul  nieihods  ot  I  .ml  i  detection,  isolation,  and  iceoverv  that 


were  common  to  all  the  spacecraft.  The  methods  utilized  in 
the  design  and  implementation  have  evolved  in  parallel  with 
the  spacecraft  requirements.  As  requirements  for  long  life  and 
high  reliability  have  become  more  stringent,  specialized 
functions  have  evolved,  with  satisfactory  in-flight  experience 
serving  js  the  basis  for  broad  acceptance.  Typical  of  the 
specialized  techniques  employed  by  spacecraft  to  protect 
against  specific  fault  classes  are:  cross-strapping,  voters,  watch¬ 
dog  timers,  parity  checks,  data  coding,  counters,  and  switching 
networks.  These  fault -handling  techniques  pertain  generally  to 
subsystems.  At  the  system  level,  about  all  that  is  currently 
done  in  a  fault  situation  is  to  put  the  spacecraft  in  a  safe-hold 
mode  to  await  ground-operator  command.  It  is  the  inclusion 
of  onboard  detection,  isolation,  and  recovery  mechanisms  for 
the  purpose  of  reducing  all  ground  interaction  that  is  the 
distinguishing  characteristic  of  ASM. 

a.  Detection  mechanisms.  Present  spacecraft  design  tech¬ 
niques  rely  on  parametric  data  telemetered  to  ground 
operators  for  fault  detection.  Generally,  faults  are  inferred 
from  the  nonreal-time  analysis  of  such  data.  However.  ASM 
requires  the  timely  detection  of  faults  by  either  direct  para¬ 
medic  measurement  or  incipient  fault  prediction  using  direct 
measuiement  and  onboard  trend  analysis  techniques.  Because 
of  mass  and  power  constraints,  measurement  technology 
becomes  a  leading  technology  driver.  More  extensive  Use  of 
watchdog  timers,  parity  checks,  error-coding  schemes,  and 
counters  is  anticipated.  Concerns  about  the  integrity  of 
detection  mechanisms,  utilizing  special  test  routines  and  oi 
additional  detection  mechanisms  must  also  he  resolved. 

/>.  Isolation  lncehunisms.  Extremely  high  reliability  switch¬ 
ing  techniques  dominate  fault  isolation  strategies,  which 
involve  the  jhiluy  to  lemove  faulty  components  from  the 
system  pine  to  iccsiahlishing  a  "tault-free".  fully  operational 
conlieuiation.  At  issue  is  the  reliability  ot  the  switching 
mechanisms  themselves.  Redundant  switching  strategies, 
powei  conliol.  ,uid  special  lest  routines  to  assess  switch 
integtity  dining  latent  intervals  are  requited. 

t  Recovery  me<  hanism s  Recovery  mechanisms  lend  to 
cen lei  upon  issues  ot  lesmiice  m.m.igement  and  techniques  to 
maximize  system  peilorniaiicc  subsequent  to  l.iulls  As  such, 
they  represent  a  system  utinhute.  wheieas  detection  and 
isolation  mechanisms  aie  chaiactcii/cd  as  uhsy  stem  attributes. 
A  system  level  view  ol  i lie  available  spaceciaft  resouices 
will  be  needed,  and  so  system  li.ule-ott  studies  stnving  to 
minimize  cost  (mass,  volume,  power)  and  maximize  recovery 
potential  I rom  I, mils  are  requited. 

2.  Spacecraft  methodologies.  In  general,  t he  procurement 
management  policies  have  been  considered  adequate  hy  the 
study  participants,  however,  new  design  procedures  are  antici- 
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pated.  The  following  discussion  focuses  on  the  need  lor  new 
design  tools  and  new  test  and  validation  procedures. 

a.  Design  tools.  Simulators  and  emulators  will  be  required 
to  provide  relative  assessments  of  the  design  and  to  assist  in 
trade-off  evaluations.  Present  reliability  methods,  however,  as 
defined  by  Mll-HDBK-217  may  not  be  directly  applicable  to 
ASM.  Areas  requiring  further  study  include: 

(1)  Software  and  firmware  reliability.  The  problem  in¬ 
creases  with  the  complexity  of  the  software,  and  total 
project  orientation  is  needed  for  success. 

(2)  Predictive  methodology  for  transient  lailure  analysis. 
Test  data  on  commercial  computer  systems  presented 
during  this  study  indicate  that  as  many  as  50‘-  to  l>0'7 
of  reported  failures  result  from  transient  faults. 

/>.  Testing.  The  present  testing  techniques  have  been  shown 
to  be  adequate  lor  current  spacecraft.  For  an  ASM  spacecraft, 
however,  new  testing  methods  may  be  requited  because 
( I )  testing  of  ASM  functions  must  be  done  at  each  step  in  the 
integration  process;  (2l  new  onboard  capabilities  may  requite 
new  lest  equipment;  and  (51  the  possibility  of  ASM  masking  a 
lailure  prior  to  launch  must  be  detected 

c  Validation  A  major  element  of  validation,  specifically 
relevant  to  ASM.  is  reliability  validation.  As  noted  at  a  NASA 
conference  on  validation  methods  research  for  tault-toleiani 
avionics  and  contiol  systems  (Ref.  9); 

"A  traditional  approach  to  reliability  validation  is 
the  hletesting  method  in  which  one  takes  n 
statistically  identical  copies  of  the  system  under 
test  and  temnnates  the  lest  after  r  (l  V  r  n) 
systems  have  tailed  l Nine  the  accumulated  time 
on  test,  one  can  derive  a  point  estimate  and  con¬ 
fidence  intervals  tor  tin  mean  life  of  (he  system. 

These  statistical  techniques  also  allow  one  to  cal¬ 
culate  confidence  intervals  lor  system  reliability 
foi  any  given  mission  lime.'’ 

,  the  mnnbet  of  systems  required  to  be  put 
under  lest  increases  monotonically  with  the  reli¬ 
ability  of  the  system  being  tested.  Furthermore, 
the  validation  problem  is  compounded  because  the 
cost  of  an  individual  copy  of  the  system  also 
increases  remarkably  with  its  reliability." 

”,  ...  applying  traditional  lileiesling  techniques 

implies  unreasonably  high  validation  costs." 

The  conclusion  ol  the  NASA  workshop  is  that  a  new  valida¬ 
tion  methodology  is  required  tor  fault-tolerant  avionics  and 


control  systems.  This  conclusion  is  also  appropriate  for  long- 
lived.  highly  reliable  spacecraft  systems. 

B.  Fault-Tolerant  Computing  Technology  Assessment 

The  following  conclusions  summarize  the  state  of  the  art 
in  fault-tolerant  onboard  computers,  and  the  applicability  ol 
extending  the  methodology  of  fault-tolerant  computing  to 
ASM. 

1.  Machine  availability.  No  fault-tolerant  computers  are 
currently  available  for  use  on  ASM  spacecraft,  lire  An  Force's 
Fault- Tolerant  Spaceborne  C  omputet  is  the  most  viable  candi¬ 
date  lor  use  in  a  1‘>X5  ASM  demonstration,  since  it  is  the  only 
lauli-loleiani  onboaid  piocessor  in  an  advanced  state  of  devel¬ 
opment.  A  breadboard  has  been  constructed  and  verified.  The 
tnajot  obstacle  to  its  use  is  the  development  of  low-powet. 
radiation-baldened  1  SI.  This  is  an  enabling  technology  toi  all 
advanced  digital  systems  in  CSAF  spacecraft  and  is  being 
treated  as  a  problem  of  high  priority  and  urgency . 

The  Fauit-loleiant  Spaceborne  Computer  may  be  ham¬ 
pered.  however,  because  it  is  ini  pie  men  led  as  a  single  urn- 
processor.  It  is  expected  that  future  spacecraft  architectures 
will  tend  toward  a  ,  rolifeiation  of  small  microcomputers  m 
a  variety  ol  control  and  payload  subsystems.  Fault  toleiancc 
will  need  to  be  distributed  tluoughout  these  distributed 
architectures  (e.g..  special  fault-detection  hardware  will  be 
requited  in  each  small  subsy  stem  computer  I.  and  a  hierarchy 
of  iccoveiy  mechanisms  will  be  employed.  Therefore  it  is 
nnpoitant  that  fault-tolerant  distributed  computing  sy  stems 
be  developed  lot  futuie  generations  of  ASM  spacecraft.  The 
Building  Block  FaitltToleiant  Computer  is  a  distributed 
computing  system  being  developed  toward  that  objective.  It 
is  not  as  tar  advanced  m  development  as  is  the  Fault-Tolerant 
Spaceborne  Computer .  but  it  may  he  available  as  an  alterna¬ 
tive  flight  system  in  the  future. 

2.  Fault-tolerance  methodology.  Many  of  the  techniques 
employed  In  lault-toleiant  computer  design  can  he  extended 
beyond  the  computing  subsystems  to  the  ASM  spacecraft 
system.  This  has  already  been  demonstrated  to  a  considerable 
extent  ten  years  ago  in  an  ASM  study  ot  the  NASA  Tlteimo- 
electric  Outer  Planets  Spacecraft  (Ret  .  10).  Some  of  the  fault 
tolerant  computing  methodologies  that  s.in  be  appbed  to 
spacecraft  are  listeil  below: 

(1)  Careful  definition  oj  fault  set  In  both  digit. d  .,ud 
spacecraft  systems,  it  is  necessary  to  carefully  define 
and  analyze  tiro  fault  conditions 

(2)  I'an/r-ih  faction  algorithms  Following  a  ,.m'fu!  anal¬ 
ysis  ot  taulls.  it  is  necessaiy  to  determine  the  nu\!u 
tnsnis  by  which  they  are  detected.  In  both  digital  and 
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nondigital  subsystems,  this  takes  the  form  of  special 
sensing  hardware  and  software. 

(3)  Fault  containment:  To  simplify  fault  recovery,  in  both 
computers  and  spacecraft,  it  is  necessary  to  design  the 
system  so  that  the  spread  of  damage  caused  by  a  fault 
is  minimized.  Whenever  possible,  it  is  advantageous 
to  detect  and  contain  faults  at  the  lowest  possible 
level. 

(4  I  Hierarchic  fault  rcetnere  Fault  detection  and  recovery 
in  computers  is  done  in  a  hierarchic  fashion.  Recovery 
may  he  implemented  at  various  system  levels  depend¬ 
ing  upon  the  origin  and  severity  of  the  fault.  This  meth¬ 
odology  clearly  applies  to  spacecraft  systems  as  well. 

(5)  Reliability  moJcling.  Reliability  and  performance 
models  developed  tor  tault-toierant  computers  are 
applicable  to  ASM  spaceman  The  concept  of  “cov¬ 
et  age".  which  desetihes  the  effectiveness  of  the  lault 
h'coierv  mechanisms,  is  ven  important  in  noth  com¬ 
putet  and  spaeeetaft  systems.  Fxten»ions  ot  existing 
reliability  and  performance  models  for  computes  are 
u.  unintended  for  spacecraft  evaluation 

IM  Mjlhtuiiciv  Cut  rent  work  on  the  validation  of  lault 
tolerant  corny  tors  will  be  applicable  to  spacecraft 
systems.  Fault-tolerant  computers  and  ASM  design 
should  make  it  much  easier  to  verily  the  integrity  «-t 
the  lault  recovery  mechanisms  without  insenina  lauds 
into  the  system.  Techniques  for  and  results  of  experi¬ 
mental  testing  of  fault-tolerant  computers  will  he  ot 
considerable  value  to  ASM  spacecraft  engineers. 


(7)  Resource  management :  In  complex  computing  systems 
and  in  spacecraft  there  is  a  resource  management  prob¬ 
lem  associated  with  fault  recovery.  As  an  attrition  of 
resources  occurs  due  to  faults,  the  system  must  op¬ 
timally  allocate  those  resources  remaining. 


IV.  Summary  Observations 

Reduction  of  space  system  vulnerability  can  be  achieved 
by  moving  the  control  operations  cetuet  function'  on  hoard 
the  spacecraft .  To  do  this,  an  autonomous  spacecraft  mainte¬ 
nance  capability  is  requited  that  III  mcoip-uates  design 
features  that  penmt  the  spacectalt  to  tolerate  Units  ami 
(31  eliminates  the  need  fot  routine  gtound  contact.  The  null- 
taiy  spacecraft  ate  cutrently  desioed  toi  giound-conttollevi 
m  imtet'.mcc.  and  it i  teims  ot  the  ASM  capabilities  deviibed 
above,  they  cannot  now  ..utononiously  maintain  then  own 
he. ill!:  and  welt.-.v  Ihc  planetary  spacecraft  described  ate 
a  step  close:  i:  the  -.’".li  but  ate  not  there  themselves.  Tims, 
although  sot’s-  pioneering  work  m  ASM  has  been  done,  it  is 
sill!  m  its  tit  *  aticy  hi  addition  to  the  enhancement  of  the  cut- 
lent  capabilities  that  have  .ilo'ady  been  mentioned,  the  study 
cioiip  loiesc.'s  ts\o  maim  technological  developments  that  are 
needed  to  enable  ASM  These  ate  Ilia  faiill-lolerant  data 
processing  system  and  id)  an  autonomous  navigation  capa¬ 
bility  (to  reduce  the  dependence  on  the  control  opetations 
ectiietl  The  study  gi'-up  is  unanimous  in  Us  assessment  that, 
with  these  vlevelopments.  the  ASM  capability  can  be  made 
available 
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The  ASM-Enhanced  System 


I.  Candidate  Design  Requirements 

Ci'iMitront  with  the  state-ot-the-ai t  spaceman  system  ami 
, .ml t - r i >lc t an t  computer  assessments.  tlio  study  slump  detei- 
mined  a  set  ol  ASM  refinements  to  convey  ASM 

.rtinbutes.  si s  that  a  spaceman  concept  e.  uM  he  established 
I  he  impact  o'  these  refinement'  on  'mure  An  I  urce  space- 
^  ’.if  -tents  was  then  analyzed  I  ■■Ih'uine  ate  the  candidate 
i  mceptual  design  ro> ]ti n t-incn r s  developed  lium  this  study 

tit  I II  lir  l-oric  v/  >£/<  i  eraji  lamb  lied  utter  Man/:  /V.w 
s  hall  mat  the  ASM  n  amremenls  listed  be  Am  On 
tilt'  dale,  the  Derailment  ot  Delense  would  requite 
ali  siihsei|i tent  'p.uesiait  purchased  to  melmle  the 
lulls  "pei.i'iotial  ASM  eapahtlt  \ 

i  l*i  t'M  to  ihi'  date,  il  i'  desirable  M  add  iiKtemenlal 
ASM  '.ipahihiies.  consistent  with  system  perl ai- 
m.nse.  as  ihev  ate  developed  ) 

I i  Tin  ASM  spat ay  ratt  shall  operate  without  a  ground 
snpp  i n  i ,  mtri  •!  link  jor  ti/'  in  f>(l  dues  without  Jcgra 
datum  oj  peril  mr.ani  r  This  is  the  essence  ot  autoito- 
nious  opeiaiMiis  The  spaeeetali  will  function  until 
er"uml  suppoii  is  available  or  desirable  trorn  the 
viewpoint  ol  the  ground  support  team. 


(At  The  ,-l.SU  spacecraft  shall  operate  with  not  mure  than 
I  O'"  degradation  of  key  Junctions  our  a  nmioiith 
period  of  autonomy.  Till'  toquireinen t  '« i','  set  some 
sizing  eons'raints.  such  as  data  storage,  and  refine 
some  definition  of  loss  of  performance.  I;  sti esses 
the  need  lot  continuous  function  of  the  spacecraft 
on  an  "ad  hoc"  basis  if  scheduled  ground  support  is 
not  provkvd.  The  10"  theme  Is  somewhat  arbitrary: 
however,  at  the  end  of  6  months,  the  performance  of 
(he  entire  sy  stem  shall  be  at  a  useful  level 

(41  Jhc  ASM  spacccrajt  shall  interact  with  the  ground. 
sii/'/>ori  segment  jor  not  more  than  aO  minutes  to 
perform  ali  ret/ Hired  xupf>ort  Junctions  without  per¬ 
formance  degradation  After  a  period  of  autonomy, 
it  is  rebutted  that  the  spacecialt  and  ground  suppoii 
petlorm  all  the  requited  support  functions  in  this 
window  The  lunctions  include  (a)  downlink  ol  all 
stored  maintenance  hisioty.  ( b )  uplink  of  all  data 
load  (such  as  siar  tables  and  ephemcris).  (c)  redun¬ 
dancy  manageimnl.  and  (d)  testing.  Specification  ot 
(he  duration  ol  the  support  window  is  mission 
dependent  The  intent  would  he  an  uplink  support 
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period  approximately  the  same  as  that  required  lor 
non-ASM  spacecraft. 

(>)  ASM  shall  not  change  the  design  lifetime  of  the 
spacecraft,  [he  imposition  of  the  requirement  for 
ASM  on  a  spacecraft  development  is  in  addition  to 
mission-imposed  requirements,  particularly  the  design 
liletime.  ASM  will  impact  the  design  methodologies. 
Such  design  issues  as  depth  of  redundancy  must  take 
into  account  the  rate  at  which  resources  are  used  up 
with  the  ASM  design  so  that  the  total  lifetime  or 
mean  mission  duiation  shall  not  he  reduced. 

((')  I.VU  shall  not  change  the  performance  of  the  spaa ■- 
i  raj f  or  its  payload.  All  requirements  placed  upon 
the  spaeeeratt  development  tor  performance  oi 
either  spacecraft  or  payloads  shall  not  he  affected 
by  the  presence  ol  autonomous  spacecraft  mainte¬ 
nance.  1  he  spaeeeratt  must  he  designed  to  provide 
these  peiiomunce  levels  in  the  absence  o!  frequent 
ground  contio!  interaction.  Specific  additional 
spacecraft  lunations,  such  as  navigation,  may  he 
lequned  to  meet  the  autonomy  requirement.  It'  so. 
the  peitoimance  ol  these  tuncnons  (e  g.,  navigation 
accuracy  i  musi  suppoit  non-ASM  system  peitoi- 
At. nice  requirements. 

t  A  Pie  ASM  spaeeeratt  shall  he  ahh  to  recover  irom 
failures  that  have  'wen  Jelined  a  prion,  ami  tin 
probability  that  any  pariitular  jailure  was  dijined  a 
nrtori  shall  he  ‘  out-,  [lie  ASM  functions  include 
m> mitoi mg  the  spacecraft  pel ! or inaiu  e  foi  faults  ami 
:'to'i|enf  sy  nip, loins.  anJ.  :n  the  pies ci.\c  o|  ,j  i.mit. 
tucntttymg  is*  l.iMtig.  and  impieme'tutn:  the  recover. 

. . .  at  ;>oth  ai -■■•.stem  ami  >tem  levels  the  a 

pttoii  analysis  shall  he  Mil Inn  ntiy  complete  that, 
dunng  the  liletime  ol  the  spaces  i.ifl.  at  least  us  ;  ol 
the  Dilutes  fe  e.,  where  some  component  has  tailed) 
will  he  identified  m  tins  inannei  (the  cov-uage  is 
'US  ).  firmpotiinl  tailuies  wheiein  multiple  symp¬ 
toms  occut  simultaneously  or  neai  simultaneously 
dunng  the  detection  and  recovery  period  can  he 
esempted  Irom  this  leqiiuement. 

IS)  hollowing  laiunh.  the  .I.VU  s/> atceratl  shall  go 
through  a  /■<  find  of  oit-orlut  ,  hc<  kout  and  tnittaUza 
tion  oj  the  same  duration  as  that  of  a  comparable 
non  ASM  spacer  rail  I  he  autonomy  leqiinements 

discussed  hen:  .lie  applied  to  the  operational  penoil 
ol  the  sp.iceciat! .  which  is  deemed  to  begin  following 
the  on  oibii  checkout  period  In  the  checkout  period, 
maintenance  will  he  undei  ground  control,  will) 
autonomous  capabilities  turned  on  m  oil  as  appro 
I’m. ite  Since  the  addition  ,-t  ASM  does  add  ceitain 


functions,  operating  modes,  and  complexities  to  the 
spacecraft,  tnese  must  also  he  checked  out  during  the 
same  period.  Following  checkout,  all  autonomy 
requirements  will  apply. 

('>)  The  spacecraft  shall  process  and  store  all  onboard 
management  data  required  for  ground  support,  and 
shall  telemeter  the  data  during  the  ground  support 
periods  upon  ground  command.  'Pie  capability  shall 
handle  all  necessun  data  for  t>  months  No  matter 
how  confident  designers  may  be  of  the  maintenance 
capability  ol  the  spaeeeratt,  it  will  he  necessary  to 
leave  a  lecord  for  ground  support  (an  audit  trail) 
Without  this  information,  the  ground  support  func¬ 
tion  cannot  evaluate  the  state  of  the  spacecraft  and 
use  the  record  of  performance  to  extend  the  liletime 
of  the  spacecraft,  develop  or  implement  alternative 
operating  modes,  or  improve  future  designs. 

(10)  The  ASM  spacecraft  shall  transmit  a  message  to  the 
ground  at  the  Jirst  opportunity  Jo/lowing  any  on- 
hoard  Jault-managemcnt  activity  Whenevei  an 
incident  occurs  that  requires  maintenance  activity  in 
response  to  failure  symptoms,  n  is  important  that  the 
giouttd  he  given  the  opportunity  to  review  the  action 
and  to  verity  the  status  and  mode  of  the  spaeeeratt. 
Thus,  a  telemetry  message  indicating  that  some 
activity  had  taken  place  would  he  sent  to  the  ground 
at  the  firs!  pass  over  an  appropriate  ground  station. 
I  Ins  type  ol  signal  may  he  coded  into  the  usei  data 
to  tugger  an  alarm  at  the  ground  support  station. 
Sending  of  the  message  does  not  abolish  the  obliga¬ 
tion  ot  the  spacecraft  to  letatn  the  data  for  the 
maximum  period,  and  to  continue  to  operate  in  an 
autonomous  inannei  foi  the  established  periods. 

Ill)  Pie  ground  support  shall  be  able  to  override  ASM 
management  activities  for  the  system  and  the  sub 
systems.  While  the  ASM  spacecraft  shall  have  the 
ability  to  peitoim  redundancy  management  in  tire 
presence  of  an  apparent  fault  oi  ptohlem.  u  is  neces¬ 
sary  that  the  ultimate  control  ovei  these  functions  he 
maintained  at  the  ground.  and  that  the  spacecraft 
shall  allow  foi  ground  communication  that  overrides 
and  can  reverse  the  prior  decisions  ot  the  ASM  linn 
ttons.  The  capability  is  necessary  so  that  the  system 
will  he  able  to  lecovei  from  such  learning  cm ve 
nncei i .mi tics  as  misdiagnosed  ptohlcms  oi  design 
lljws.  In  this  way.  non  failed  components  may  he 
iccycled  hack  into  the  configuration  inventory  or 
the  spaceciafi  alternate  modes  of  functioning  may  he 
utilized  to  make  use  of  partial  capabilities  ol  compo 
non ts  lit  terms  of  a  lueiarcliic.il  decision  tree,  the 
giound  support  peisonnel  shall  occupy  the  lop  level 
to  maximize  system  peitoimance. 
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(12)  The  source  of  last  resort  for  fault  isolation  anj  recov¬ 
ery  shall  be  the  ground  support.  The  ASM  spacecraft 
shall  be  designed  to  recognize  when  it  lias  been 
unahle  to  isolate,  remove,  and  recover  performance 
following  a  fault.  When  this  occurs,  the  spacecraft 
shall  take  action  to  protect  itself  from  self-injury  or 
dissipation  of  resources  (such  as  an  engine  tiring  limit 
cycle  that  would  consume  propellant),  and  await 
ground  intervention. 

Satisfying  these  design  requirements  implies  the  movement 
of  the  control  of  routine  maintenance  operations  from  the 
ground  to  the  spacecraft.  The  ground  segment  will  assume  a 
supervisory  role,  always  maintaining  the  ability  to  overt ide 
ASM  actions,  but  allowing  the  spacecraft  to  initially  handle 
its  own  maintenance  functions.  The  space  segment,  on  the 
other  hand,  will  become  more  complex  due  to  the  added 
operations  it  must  perform,  including  onboard  navigation 
(eliminating  the  need  for  routine  uplink)  and  fault  detection, 
isolation,  and  recovery.  To  handle  those  added  operations,  a 
fault-tolerant  data  processing  subsystem  and  an  autonomous 
navigation  subsystem  will  be  required.  The  major  benefits  of 
ASM  would  then  include:  (I)  reduced  system  vulneiahilily. 
because  it  is  no  longer  dependent  upon  the  ground  station 
or  possible  incorrect  commands  by  human  operators,  and 
(2)  faster  recovery  from  failures  (seconds  instead  of  hours  01 
possibly  days)  because  recovery  procedures  would  stair 
immediately  upon  fault  detection. 


II.  Impact  on  the  Ground  and 
Space  Segments 

Some  examples  of  operations  and  maintenance  functions 
that  presently  are  accomplished  by  the  ground  segment,  but 
with  ASM  will  be  accomplished  by  the  spacecraft,  include: 

( 1 )  Attitude/pointing  commands 

(2)  Thermal  control  loop 
(2)  Power  management 
(4)  Fault  nionitor/isolaiion 
<s)  fault  tolerant  computation 
(0)  Fault  switching 

(7)  load  switching 
(X)  Trend  analysis 

A  reduction  in  ground  control  activity  can  cleaily  be  seen  It 
should  be  remembered,  however,  that  in  its  supervisory 


capacity,  the  ground  segment  will  have  the  ultimate  authority 
and  responsibility  in  all  situations.  As  total  reduction  in 
ground  contiol  will  not  ovvui  al  one  lime,  a  tiansition  phase 
will  be  required.  Tills  phase  will  enable  (I  )  intlight  measure¬ 
ments  of  effectiveness  loi  ASM  ovei  a  diverse  sel  ot  updating 
conditions.  (2)  the  development  ot  undeisiuudable  and  pie- 
dictable  ASM  operations,  and  (7)  simultaneous  siippoit  ot 
both  ASM  and  non-ASM  operational  spaceciatt 

The  increase  in  spaceciatt  autonomy  will  mean  an  increase 
m  the  complexity  of  the  spaceciat  t  While  ibis  mciease  in  com¬ 
plexity  must  not  introduce  catastrophic  tailmes  ui  icJuce  me 
payload  per loimauce.  it  will  lend  lu  mciease  the  spaceciatfs 
mass,  power  consumption,  and  total  cost.  Given  the  sun:\ 
group's  knowledge  of  cuiieni  and  ptojected  technology  .  the 
following  heuiisiic  estimates  were  established  as  leasonable 
design  goals  lor  an  ASM-enhanced  spaceciatt 

Power  consumption  ASM-.  Iff-'  ol  total 

Mass  impact :  ASM  n  5":  ot  total 

Cost  impact:  ASM  v.  IU  ot' life-cycle 

Cost 

III.  A  Hierarchical  Description  of  the 
Space  Segment 

The  following  sections  describe  what  the  study  p.uticipants 
believe  will  be  the  impact  of  ASM  on  a  generalized  spacecraft 
system.  In  these  descriptions,  the  following  assumptions  have 
been  made. 

(1)  The  ASM  requirement  is  added  to  a  new  spaceciatl 
before  design. 

(2)  ASM  technologies  will  be  available. 

(7)  Payload  is  treated  as  a  subsystem,  except  for  usei  data 
(low. 

(4)  As  long  as  mission  objectives  are  met.  normal  space- 
ci al i  functions  may  be  interrupted  dining  ceilain  fault 
recove i y  pn iced u res. 

A.  System  Architecture 

System  aiclinecture  evolves  tiom  the  mission  requiiemenls. 
and  includes  the  hardware  organization,  data  flow  chaiacteiis- 
lics.  and  (il  a  digital  system)  the  hierarchical  operating  s\  stem. 
The  system  must  judiciously  allocate  the  available  lesources 
and.  upon  command,  must  report  all  ASM  actions  (including 
parametric  data)  to  the  contiol  opeiattotis  centei.  Finally  ,  it 
must  also  msiiie  Us  own  integiity  (lluoiigli  self-diagnosis)  so 
that  inconect  actions  and  ground  system  lock-out  modes  aie 
eliminated 
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An  example  of  a  system  architecture  that  could  be  used  tor 
ASM  is  shown  in  Fig.  3.  This  is  characterized  by  both  distrib¬ 
uted  and  central  processing  system  attributes.  Efficient  man¬ 
agement  ol  the  spacecraft  resources  based  upon  prespecified 
algorithms  require  centralization  of  high-level  decision  making. 
This  would  he  accomplished  by  a  fault-tolerant  processor, 
serving  as  the  spacecraft  central  controller,  augmented  by 
processors  located  in  each  of  the  subsystems  as  appropriate. 
In  addition  to  the  new  subsystems  already  mentioned,  the 
architecture  should  also  accommodate  additional  mission- 
unique  subsystems. 

The  system  architecture  example  described  above  is  one  of 
several  possible  architectures  for  an  ASM  spacecraft.  While  a 
detailed  investigation  of  the  various  architectures  was  not  a 
part  of  this  study,  the  participants  believe  that  such  an  effort 


should  be  undertaken  as  one  of  the  first  tasks  ol  jn  ASM 
development  program. 

Whichever  architecture  is  chosen,  the  study  group  believes 
that  a  "layered"  fault  protection  scheme  should  be  used, 
enabling  fault  containment  at  the  lowest  possible  level  to 
minimize  subsystem  interdependencies  resulting  from  fault 
propagation  (including  data  contamination).  This  laull  pio- 
lection  scheme  is  illustrated  lit  Fig.  4  In  this  scheme,  individ¬ 
ual  subsystems,  tindei  system  control,  will  diagnose  local 
failures  and  take  collective  action.  Ambiguous  problems  result¬ 
ing  from  failures  within  the  interfaces  between  subsystems 
will  requite  diagnostic  loutmes  and  hardwaie  to  pin-point  the 
failuie.  Some  tiinesolved  sy  stem  issues  include  the  ptoblcnis  ol 
transients,  false  failure  alarms,  multiple  faults,  and  laults 
within  the  fault-ioleiaiit  computing  system.  Once  the  system 
has  been  designed,  test  and  validation  proceduies  musi  be 
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Fig.  4.  "Layered"  architecture  of  fault  procesaing 


formulated.  Finally,  there  should  be  a  demonstration  program 
showing  that  the  requirements  for  ASM  are  met  without  com¬ 
promising  either  the  mission  lifetime  or  payload  perlormance. 


B.  Subsystem  Impact 

ASM  will  affect  the  traditional  subsystems  (attitude  and 
articulation  control,  power,  telemetry  and  data  handling, 
payload,  communications,  propulsion,  and  thermal  control) 
by  requiring  that  they  add  the  capability  of  diagnosing  and 
handling  their  own  faults.  The  conceptual  design  requirements 
imposed  on  the  ASM  spacecraft,  however,  necessitate  the 
potential  addition  of  two  new  subsystems.  These  include  a 
fault-tolerant  data  processing  subsystem  and  an  autonomous 
navigation  subsystem. 

The  need  to  integrate  independent  subsystems  with  indi¬ 
vidual  processing  requirements  into  a  control  hier.iichy  for  the 
purpose  of  managing  and  reporting  fault-protection  leads  to  a 
requirement  tor  a  fault-tolerant  data  processing  subsystem. 
Because  of  the  potential  for  power-interrupt  failure  modes, 
this  subsystem  must  include  limited  nonvolatile  backup  mem¬ 
ory  resources  tor  selected  critical  program  and  data  storage. 

The  requirement  for  six  months  ot  unattended  operations 
necessitates  an  autonomous  navigation  capability.  The  prob¬ 
lems  ol  vehicle  position  and  velocity  are  dependent  upon  mis¬ 
sion  requirements  for  attitude  control  and  pointing.  It  involves 
the  characterization  (modeling)  of  complex  gravitational 
fields,  including  the  effects  of  Fartli  tiguie  and  multibodv 
(Iiarth.  Moon.  Sun)  interactions  that  perturb  the  vehicle  posi¬ 
tion  and  velocity.  As  attitude  control  requirements  become 
more  stringent,  more  precise  models  and  advanced  sensors 
permitting  real-time  drag  acceleration  measurements  will  be 
required  to  complement  existing  menial  measurement  devices 
and  celestial  sensors. 

Finally,  the  requirements  lor  a  six-month  audit  trail  and 
onboard  trend  analysis  to  permit  fault  prediction  and  protec¬ 
tion  necessitates  storage  and  manipulation  of  a  large  volume  of 
data.  Without  ground  imks.  the  studs  participants  believe 
additional  data  storage  capabilities,  coupled  through  the  data 
netwoik  to  the  other  spacecraft  subsystems,  will  be  needed. 
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Implementation  Plan 


A.  Purpose 


I.  Introduction 

This  section,  together  with  the  Research  Agenda  of  the 
next  section,  describes  the  study  participants’  recommended 
plan  of  attack  to  Solve  the  problem  that  prompted  the  ASM 
study:  to  satisfy  the  requirement  for  spacecraft  readiness  in 
the  face  of  the  loss  of  ground  stations.  In  contrast  with  the 
Research  Agenda  that  addresses  medium-  and  long-range 
academic  research  for  an  advanced  ASM  system  of  the  1990s. 
this  section  focuses  on  the  near-term  (next  five  years)  indus¬ 
trial  technology  development  and.  most  importantly,  the 
earliest  possible  system-level,  proof-of-concept  demonstration. 
The  plan  stresses  delivery  of  "product”  in  a  steady  stream 
from  subsystems  to  a  complete  system  tor  the  System  Program 
Offices'  consideration  and  introduction  into  flight  programs. 
In  this  sense,  the  plan  is  a  technology  program  that  is  managed 
like  a  project,  with  Incused  goals  and  milestones  to  be  met. 
While  there  is  no  provision  for  a  Right  demonstration  in  this 
plan,  a  definite  goal  has  been  to  provide  a  program  that  will 
generate  continuous  ASM  technology  "fall-out,"  which  can  be 
utilized  in  ongoing  programs  and  in  design  block  changes. 

The  program  described  below  is  preliminary:  the  limited 
resources  of  the  study  precluded  a  detailed  program  develop¬ 
ment  and  cost  estimate.  However,  the  study  participants  feel 
the  proposed  plan  described  contains  the  essentials  of  a 
workable  program  needed  to  meet  the  future  requirements 
of  the  Air  force. 


The  purpose  of  the  plan  is  to  recommend  a  coordinated  set 
of  developments  that  will  give  industry  a  demonstrated  capa¬ 
bility  to  build  an  ASM  spacecraft,  and  hence,  enable  the  Air 
Force  to  change  from  ground-dependent  to  autonomous 
operational  spacecraft  bv  I  Wf 


The  goals  of  the  plan  are: 

( 1  I  To  develop  an  ASM  technology  and  apply  it  as  early  as 
possible  to  existing  programs,  especially  DMSP.  DSP. 
GPS.andDSC'S  III. 

(2)  To  develop,  by  1985.  a  demonstrated  industrial  capa¬ 
bility  to  produce  autonomous  spacecraft,  so  that  the 
first  operational  launch  may  take  place  by  1989. 

C.  Approach 

The  approach  taken  in  preparing  the  plan  can  be  summa¬ 
rized  in  the  following  points: 

(1)  Involve  as  many  relevant  governmental  and  industrial 
organizations  as  possible.  This  will  create  a  broad  base 
of  ASM  experience,  design,  and  methods. 

(2)  In  support  of  the  first  goal,  begin  work  with  existing 
subsystem  designs:  ASM  implications  and  problems 


B.  Goals 
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must  he  characterized,  designs  and  breadboards  must 
be  modified,  and  results  demonstrated  early. 

(3)  In  support  of  the  second  goal,  begin  work  on  a  parallel 
system-level  analysis,  design,  and  hardware  program 
leading  to  a  proof-of-concept  demonstration. 

(4)  Use  as  much  available  hardware  as  possible.  Develop 
and  build  as  little  new  equipment  as  possible  to  meet 
requirements.  Acquire  engineering  test  models  of 
actual  and/or  representative  systems/subsystems  of  Air 
Force  satellites. 

(5)  Focus  on  ASM-required  changes  only;  design  life  and 
performance  advancements  not  needed  for  ASM  should 
not  be  pursued. 

(6)  Hold  frequent  reviews  and  conferences  for  technical 
information  exchange  witli  all  concerned  industrial, 
academic,  and  government  organizations. 

II.  General  Plan  Description 

The  study  participants  recommend  that  the  program  con¬ 
sist  of  four  major  elements,  prefaced  by  a  three-month  start-up 
period:  first,  an  activity  addressing  existing  programs  at  the 
subsystem  level,  producing  demonstration  products  within  two 
years;  second,  a  system-level  project  addressing  ASM-enhanced 
Air  Force  programs  with  proof-of-concept  in  five  years;  third, 
applications  research  directed  at  filling  technological  gaps;  and 
fourth,  an  advanced  system  development,  aimed  at  the  l‘WOs. 
to  provide  an  opportunity  for  unconstrained  research  to 
expand  capabilities  beyond  the  foreseeable  luturc.  These 
elements  are  denoted  as  Tasks  1,2.3.  and  4.  respectively.  The 
advanced  systems  development.  Task  4.  is  identified  for  com¬ 
pleteness,  but  because  its  products  would  not  meet  the  I ‘>80 
launch  requirement,  resources  are  not  identified.  The  Research 
Agenda  elaborates  Task  4. 

A  general  view  of  the  plan  is  shown  in  Fig.  I .  in  which  the 
arrows  indicate  typical  points  of  technology  transfer  between 
tasks  to  the  System  Program  Offices.  All  tasks  start  at  the 
beginning  of  CY8I  to  allow  program  definition  and  start-up  to 
take  place  in  the  first  three  months  of  FY81.  Task  1  is  a 
two-year  activity  that  assesses  increased  fault  detection, 
isolation,  and  recovery  for  existing  subsystems.  Design  changes 
will  be  made  and  breadboard  units  will  be  modified  to  test 
ASM  capabilities  and  benefits.  Task  2  is  a  5-year  activity  that 
includes  a  top-down  system  development  and  the  necessary 
new  subsystem  technology  developments  required  tor  ASM.  A 
pre-Phase  A  effort  is  required  to  prepare  a  procurement  speci¬ 
fication  and  to  select  the  contractor  lor  both  Task  2  and 
Task  3.  In  Phase  A,  the  mission  requirements  and  spacecraft 
design  will  be  established,  while  in  Phase  B.  the  fabrication, 


integration,  test,  and  demonstration  of  the  ASM  system  will 
be  performed.  Task  3  is  a  five-year  applications  effort  required 
to  develop  new  well-defined  subsystem  technologies.  Task  4. 
through  CY85.  is  performing  the  basic  research  for  a  "second- 
generation"  ASM  system  as  mentioned  earlier. 

III.  Task  Descriptions 

The  layout  of  the  entire  program  is  showi.  in  more  detail  in 
Fig.  5.  In  the  view  of  the  study  participants,  the  plan  repre¬ 
sents  the  best  method  of  addressing  the  urgency  of  obtaining 
an  ASM  readiness,  given  the  available  resources.  The  relative 
times  needed  to  accomplish  the  objectives  are  shown;  reduced 
funding  or  delays  in  program  start-up  will  result  in  commen¬ 
surate  delays  in  completing  the  tasks  described  below. 

A.  Task  1 :  Existing  Subsystem  Redesign  to  ASM 

The  first  task  is  a  24-month  effort  to  characterize  the  sub¬ 
systems  involved  with  ASM.  redesign  the  breadboards,  check¬ 
out  subsystem  ASM  functions,  and  provide  measures  ot 
capability  required  to  accommodate  ASM.  These  measures  will 
be  in  such  terms  as  memory  si/e  and  throughput.  Because  the 
subsystems  are  well  known,  it  is  felt  that  modifying  them  to 
include  ASM  features  will  be  the  quickest  and  most  cost- 
effective  way  to  size  the  challenge  early  and  to  incorporate 
some  ASM  capability  into  the  spacecraft.  When  success'ully 
demonstrated,  the  System  Program  Offices  could  consider 
them  for  operational  use. 

It  is  expected  that  much  of  the  design  work,  and  perhaps 
the  breadboards,  would  be  important  to  the  Task  2  effort, 
and  heavy  interaction  between  tasks  should  be  anticipated. 
The  subsystems  to  be  studied  are  (ranked  by  their  ASM 
importance):  attitude  and  articulation  control,  power,  telem¬ 
etry  and  data  handling  (including  tape  recorders),  payload, 
communications,  propulsion,  and  thermal  control.  Stiucture 
and  mechanical  devices  are  not  included  because  their  design 
is  little  impacted  by  ASM  requirements.  It  is  recommended 
that  two  contractors  perform  on  each  subsystem  'o  gain  a 
diversity  of  experience  for  contractor  and  program  applica¬ 
tion.  As  no  two  designs  are  the  same,  additional  infoimaiioii 
will  he  gained  from  this  approach  to  broaden  the  data  base. 

The  first  six  months  is  spent  on  design  study.  The  subsys¬ 
tem's  fault  characteristics  will  be  examined,  and  the  fault 
detection,  isolation,  and  recovery  techniques  will  be  devel¬ 
oped.  The  hierarchical  assignment  of  fault  recovery  between 
faults  totally  handled  within  the  subsystem  and  those  “passed 
on"  to  the  system  for  action,  will  be  developed.  Evaluation  of 
the  reliability  of  sensors  and  switching,  which  are  essential  to 
"error  free"  ASM.  will  be  done.  Changes  in  design  techniques, 
instrumentation,  and  associated  software  or  firmware  as  well 
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Fig.  S.  Autonomous  spacecraft  maintenance  program 


B.  Task  2:  ASM  System  Demonstration 


as  the  hardware  will  be  covered.  An  assessment  will  he  made  as 
to  what  benefits  accrue  in  reduced  pound  maintenance  with 
the  recommended  ASM  capabilities  in  the  subsystems.  In  the 
next  nine-month  period,  detailed  design  takes  place.  Algo¬ 
rithms  lor  ASM  will  he  defined,  coded,  and  debugged.  Hard¬ 
ware  modifications  and  software  changes  will  he  made.  ASM 
design  leatures  may  he  implemented  m  single-string  fashion  so 
that  in  this  exercise  only  the  subsystem  under  lest  will  be  fault 
tolerant. 

In  the  last  sear  ot  the  program,  the  breadboards  or  engi¬ 
neering  lost  models  and  associated  support  equipment  will  he 
modified  to  include  the  ASM  te.ituies.  and  then  tested.  The 
testina  will  he  a  rtgoious  exercising  ot  the  lault-piocessmg 
logic  by  injection  ot  all  ty  pcs  of  taults  I  he  testing  will  provide 
specific  valid  measures  of  ASM  perlormanee  and  design 
requirements  in  such  terms  as  memory  requirements,  speed, 
and  recovers  algorithms  which  can  be  utilized  by  various  pro¬ 
gram  offices  as  appropriate  in  then  ongoing  or  new  programs. 

At  the  conclusion  of  Task  I .  impacts  of  ASM  will  he  clearly 
established.  Fault  character  vs  ill  he  understood,  new  sensor 
and  switching  technology  vs  ill  emerge:  software  and  hardware 
svill  he  st/ed  to  do  the  job:  algorithms  for  handling  taults  will 
he  checked  out.  many  system  issues  will  be  discovered  for 
resolution  in  Task  1.  and  finally,  the  System  Progiunt  Offices 
will  have  an  opportunity  to  assess  ASM  applicability  at  the 
subsystem  level. 


This  second  recommended  task  is  a  five-year  activity  that 
ends  in  a  system-level  demonstration  of  ASM  Ir  is  laid  out 
very  much  as  a  typical  flight  pioiect  might  he.  hut  truncated  at 
the  system  test  of  a  prototy  pe  spacecraft  with  no  lltght  hard¬ 
ware  Innli.  The  assumption  is  made  that  the  system  denion- 
sir.iiion  will  he  achieved  by  applying  ASM  n>  one  mission, 
such  as  DSP.  DMSP.  01  C>PS.  hut  the  extension  of  this  ASM 
technology  to  all  An  Force  missions  will  be  an  active  design 
consideration.  The  reviews  are  typical,  with  only  the  System 
Test  Requirements  and  the  Pioof-of-Concepl  Acceptance 
Reviews  being  unique  to  tins  program.  The  phases  ate  typical 
as  well:  systems  analysts  and  lequiiemeni-  i eueration.  system 
design,  subsystem  design,  lubiication.  and  test,  and  system 
integration  and  lesl . 

The  analysis  and  requirements  activity  proceeds  during  the 
second  \ o.i i  and  culminates  at  the  Preliminary  Design  Review 
with  the  pioduclion  ot  ihe  Mission  and  System  Requirements 
document.  Ihe  jciivnv  includes  mission  impacts,  recovery 
strategy,  degradation  profiles,  and  data  reiurn  stutegy  as 
faults  ocem:  'ehahihty  and  risk  analyses:  opeiation  analysis 
with  ASM:  flight  giound  uadeotfs.  spaceciali  system  tauli 
analysis,  development  of  the  “lay  ered"  fault  pioleetion  sy  stem 
architecture,  fault  detection,  isolation,  and  iccoveiy  at  the  sys¬ 
tem  level,  payload  interaction  with  ASM:  and  m-fllght  naviga¬ 
tion  requuements  geneialion. 
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The  ASM  system  design  occurs  during  the  second  and  third 
year,  culminating  at  tlte  Critical  Design  Review.  The  design 
team  will  study  alternate  design  approaches;  allocate  functions 
between  hardware,  firmware,  and  software;  study  distributed 
vs  central  computing;  analyze  performance;  write  specifica¬ 
tions;  and  have  the  usual  heavy  system/subsystem  interaction 
on  design  (including  Task  1  personnel).  The  key  product  will 
be  the  Spacecraft  System  Specification,  available  at  the  Criti¬ 
cal  Design  Review.  Another  important  part  of  this  period  is 
the  system  test  requirements  to  be  imposed.  The  design  must 
allow  access  for  fault  injections  during  test,  which  may  not  be 
easy  to  implement.  The  System  Test  Requirements  Review- 
will  address  adequacy  of  testing  to  prove  that  ASM  has  a 
(light-ready  capability. 

The  fourth  and  fifth  years  of  the  ASM  system  activity  will 
be  used  to  redesign,  fabricate,  and  test  the  subsystems,  and 
then  integrate  them  and  test  the  system  for  proof  of  concept. 
Where  possible,  the  subsystems  from  Task  1  will  be  used,  but 
modifications  will  still  have  to  be  made  to  integrate  them  into 
the  overall  system  design.  Redesign,  fabrication,  and  test 
should  take  15  months.  The  subsystems  will  be  delivered  to 
system  test  at  51  months  into  the  project. 

The  test  facility  preparation  starts  at  the  beginning  of  the 
fourth  year,  and  must  be  completed  by  subsystem  delivery. 
Support  equipment  must  be  designed  or  modified  as  needed. 
It  must  be  determined  how  the  fault  injection  and  testing  will 
be  done  for  proof-of-concept  testing.  In  addition  to  the  differ¬ 
ent  states  that  the  facility  will  have  to  test,  it  must  also  be  able 
to  simulate  the  power  source,  thrusters,  spacecraft  dynamics, 
and  mechanical  devices. 

Finally,  system  integration  begins  at  4b  months,  and  proof- 
of-concept  testing  begins  at  54  months.  The  system-level  proof 
of  concept  will  be  a  full  electrical  demonstration  of  the  ASM 
system,  under  the  test  conditions  already  mentioned.  Testing 
will  be  performed  in  a  laboratory  ambient  environment. 

Throughout  the  program,  attention  will  be  paid  to  any 
spacecraft  block  changes  to  ongoing  programs  that  may  pro¬ 
vide  an  early  opportunity  for  ASM  application.  Block  changes 
will  not  necessarily  affect  the  ASM  system  demonstration 
project,  but  if  one  occurs  at  an  opportune  time,  some  of  the 
system  development  may  be  directed  toward  it. 

The  Proof-of-Concept  Acceptance  Review  is  the  final  mile¬ 
stone  irt  the  system  activity.  Test  results  would  be  examined 
for  validity  and  completeness,  and  if  the  review  is  success¬ 


ful,  ASM  will  be  demonstrated  as  a  viable,  implementablc 
technology'. 

C.  Task  3:  Applications  Research 

Task  3  is  a  new  technology  research  and  development 
activity  of  five  years  duration  that  addresses  known  gaps  at 
the  subsystem  level.  Two  are  currently  identified;  a  dis¬ 
tributed  fault-tolerant  data  processor  with  a  nonvolatile  com¬ 
puter  backup  memory,  and  an  autonomous  navigation  sub¬ 
system.  Figure  5  shows  the  development  schedule  lor  these 
items.  It  is  expected  that  the  breadboards  for  these  subsystems 
would  be  used  in  the  system  proof  of  concept.  If  not  avail¬ 
able.  appropriate  simulators/emulators  would  have  to  be 
provided.  Resources  foi  in-flight  navigation  are  noi  included 
here  because  it  is  assumed  that  currently-funded  programs 
elsewhere  can  be  expected  to  produce  the  needed  breadboard 
in  1983. 

D.  Task  4:  Advanced  ASM  System  Development 

As  mentioned  earlier,  this  effort  is  comprised  of  the  Re¬ 
search  Agenda  of  the  next  section.  The  products  of  that 
research  will  fold  into  the  "second-generation"  ASM  system  of 
the  1990s. 

E.  Program  Cost  Estimate 

A  budgetary  cost  estimate  for  Tasks  1 . 2.  and  3  is  shown  in 
Table  7.  This  does  not  include  funds  for  the  development  of 
the  autonomous  navigation  capability,  which  is  assumed  to  be 
handled  in  another  program.  These  figures  should  be  con¬ 
sidered  only  an  estimate  for  several  reasons.  First,  the  cost  of 
developing  the  new  technology  is  not  well  known.  Second,  a 
specific  mission  application  has  not  been  assumed,  and  so 
candidate  spacecraft  could  not  be  assumed.  Finally,  substanti¬ 
ating  data  was  not  provided  by  the  individual  participants. 
For  these  reasons,  a  more  definitive  cost  study  should  be  per¬ 
formed  in  the  initial  phases  of  the  activity. 

IV.  Summary 

The  Implementation  Plan  presented  here,  in  the  view  of  the 
study  participants,  represents  a  balanced,  focused  attack  on 
the  Air  Force's  spacecraft  maintenance  problems.  System,  sub¬ 
system.  and  new  technology  elements  are  all  pursued  at  a  level 
sized  to  the  difficulty  of  the  specific  ASM  challenge  while 
recognizing  the  needs  for  early  demonstrable  results  for  on¬ 
going  operational  programs.  Tlte  above  described  implementa¬ 
tion  plan  is  recommended  by  study  participants  as  the  basis 
for  the  Air  Force's  ASM  program. 
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Table  7.  ASM  program  resource  estimate 


Program 

resources.  SkJ 

,.sk 

Program  element 

OBI 

082 

0X3 

0X4 

085 

Totals 

1 

l- swing  subsystems1' 
redesign  to  ASM 

2.^00 

3.500 

800 

7.200 

: 

ASM  system  dcsignv 
and  demonstration 

500 

4.500 

7.500 

7.500 

3.000 

23.0(H) 

3 

Applications  research 

600 

H(‘0 

1 .300 

2.500 

1.200 

ft. 200 

I  otals 

4.000 

8.800 

9.600 

9.800 

4.200 

36.400 

*(  oniuctnr  costs  onl>  Al  procurement  and  management  costs  nut  included,  autonomous  navigation  development  not  included 
I  leures  are  l  Y80  dollars 
h  I  \so  contractors  per  subsystem  assumed. 

*■  Single  system  contractor  assumed 


Research  Agenda 


I.  Introduction 

A  research  program  to  support  the  development  of  auto¬ 
mated  spacecraft  maintenance  must  focus  on  the  most  critical 
problems  expected  in  that  development.  A  major  challenge  is 
to  channel  a  great  deal  of  fault -tolerance  expertise,  developed 
for  other  applications,  into  work  that  will  specifically  benefit 
the  space  program.  Fortunately,  most  of  the  ASM  spacecraft 
problems  are  shared  by  many  other  applications  (e.g..  process 
control,  avionics,  and  robotics)  and  are  sufficiently  general  in 
scope  to  be  of  considerable  interest  to  the  academic  com¬ 
munity.  Tti is  proposed  Research  Agenda  is  organized  around 
specific  spacecraft  development  problems.  An  underlying 
cause  of  most  of  these  problems  is  increasing  complexity. 
The  basic  motive  force  is  rapidly  expanding  capabilities  of  I  SI 
and  V LSI  technology.  Until  very  recently .  satellites  contained 
a  tew  hundred  to  a  lew  thousand  integrated  circuits.  Fach 
integrated  circuit  contained  a  few  gates  or  registers,  and  the 
collection  of  integrated  circuits  wete  combined  to  form  a 
system.  We  will  soon  fly  single  VLSI  chips  that  contain  thou¬ 
sands  of  gates  and  memory  cells  such  that  each  chip  is  ilselt  a 
complex  subsystem  in  a  tiny  package.  This  can  lesult  in  an 
enormous  increase  in  functional  capabilities  in  satellites 
Onboard  navigation,  very -high-performance  signal  processing, 
threat  evasion,  pattern  recognition,  and  a  host  of  other  capa¬ 
bilities  will  become  feasible. 


It  is  expected  that  fault  tolerance  will  be  an  important 
attribute  of  VLSI  design  because  of  the  problems  of  transient 
faults  and  testability.  The  very  high  complexity  of  large  VLSI 
systems  is  expected  to  result  in  transient  faults  every  few 
minutes,  or  every  few  hours.  Current  experience  indicates  a 
transient  error  rate  in  LSI  memory  of  one  error  per  hour  pet 
million  bits,  liven  it  this  tale  is  reduced  an  order  ot  magnitude, 
impaired  operation  will  occur  unless  the  spacecraft  system  is 
designed  to  detect  and  recover  automatically  from  these  fault 
conditions  The  problem  of  thoroughly  testing  complex  VLSI 
circuits  has  only  recently  been  recognized.  Many  existing 
devices  are  essentially  untestable  and  design  taults  are  uncov¬ 
ered  in  the  field  after  prolonged  usage.  Since  the  only  access  to 
a  finished  device  is  thiough  a  limned  numbei  of  pins,  it 
becomes  nearly  impossible  to  exercise  all  internal  states  of  a 
device  containing  thousands  ol  transistors.  Testable  design 
methodologies  have  been  recognized  as  a  high-priority  research 
problem  in  industry,  and  is  even  more  critical  for  space  appli¬ 
cations 

New  and  laigely  unexplored  problems  are  expected  at  the 
system  architecture  level  of  space  systems.  Proliferation  of 
specialized  microelectronic  controllers  in  spacecraft  sub¬ 
systems  will  lead  to  more  complex  cooperation  between  sub¬ 
systems,  between  the  spacecraft  and  ground,  and  pet liups 
between  different  spacecraft.  Consequently,  the  system 
organization,  software,  and  fault-tolerant  aspects  of  space- 


craft  will  have  lo  become  correspondingly  more  complex.  A 
hierarchy  of  computing  processes  is  envisioned.  This  implies 
more  onboard  monitoring  circuitry  to  detect  faults  before 
errors  propagate  through  the  system,  making  diagnosis  and 
recovery  extremely  difficult.  Automatic  trend  analysis  may  be 
employed  to  record  and  discover  new  error  patterns,  and 
heuristic  recovery  algorithms  may  be  required  to  recover  from 
unanticipated  faults. 

In  summary,  there  exist  a  variety  of  research  areas  that  are 
rich  in  both  substance  and  applicability,  and  are  essential  to 
the  development  of  future  space  systems, 

II.  Research  Plan 

Recognizing  that  resources  are  limited,  the  following  re¬ 
search  plan  is  broken  into  five  areas  that  are  essential  to  future 
ASM  development:  (1)  VLSI  technology,  (2)  architecture  of 
advanced  ASM  systems.  (3)  software  fault  tolerance.  (4 )  mod¬ 
eling  and  analysis,  and  (5)  supporting  development.  In  terms 
of  criticality .  they  are  listed  in  descending  order.  Subsystem 
technology  and  especially  related  VLSI  issues  must  he  resolved 
no  matter  what  architecture  is  chosen.  An  understanding  of 
sy  stem  architecture  is  necessary  to  make  modeling  and  analysis 
more  useful  and  relevant. 

A.  VLSI  Technology 

Testing  of  LSI  devices  is  a  serious  and  expensive  problem 
in  current  spacecraft.  It  will  be  a  critical  issue  in  ASM  systems 
because  n  is  necessary  to  detect  faults  very  quickly  alter  their 
occurrence,  so  that  autonomous  recovery  mechanisms  can 
restore  the  spacecraft  to  normal  operation  with  minimal  dis¬ 
ruption  of  performance.  This  research  area  has  two  compo¬ 
nents:  ( I  )  self-testing  VLSI,  and  (2)  on-chip  redundancy  . 

1.  Self-testing  VLSI  The  first  goal  ol  tins  component  is 
to  develop  methodologies  to  design  VLSI  chips  that  are 
( I )  thoroughly  testable  prior  to  normal  operation,  and  (2)  self- 
checking.  A  methodology  for  designing  self-checking  circuitry 
lias  been  developed  that  allows  the  chip  to  detect  internal 
faults  concurrent  with  normal  operation.  We  must  learn  to 
design  a  chip  that  will  be  fully  exercised  and  tested  during 
normal  operation.  Lven  it  we  can  detect  a  fault  when  it  occurs, 
it  may  he  months  or  years  before  a  complex  chip  m  normal 
operation  enters  a  faulty  stale.  Thus,  development  of  "easily" 
testable  circuits  is  a  high-pnority  research  Hem. 

2.  On-chip  redundancy.  A  second  goal  ol  tins  research  is  to 
investigate  t  ho  use  of  on-chip  redundancy  to  improve  y  ield  and 
chip  reliability.  Although  the  existence  of  catastrophic  failure 
modes  make  it  necessary  lo  back  up  individual  chips  with 


spares,  the  use  of  on-chip  redundancy  may  greatly  improve 
chip  reliability  and  system  life. 

B.  Architecture  of  Advanced  ASM  Systems 

This  area  includes  the  hardware  and  software  organization 
to  achieve  fault  tolerance  in  highly  complex  ASM  spacecraft. 
Tliis  work  must  take  into  account  the  trend  toward  prolifera¬ 
tion  of  computers  in  spacecraft  subsystems,  and  it  should  be 
directed  toward  future  space  systems  in  which  dozens  of  dis¬ 
tributed  computers  may  be  used.  It  should  address  the  impacts 
of  VLSI  in  spacecraft  architecture,  performance,  and  ASM 
capability  It  is  expected  to  support  ASM  spacecraft  develop¬ 
ment  beyond  I9l>0. 

To  effectively  involve  the  academic  community  in  space¬ 
craft  system  research,  it  will  probably  be  necessary  for  the 
LSAF  to  develop  a  set  of  strawman  system  requirements. 
Most  members  of  die  academic  community  are  not  familiar 
with  the  unique  problems  of  space  systems  (e.g..  power, 
weight,  volume,  uplink  and  downlink,  instruments,  testability, 
command  interfaces,  and  subsystem  operation).  Thus  careful 
problem  definition  is  required  to  focus  this  work  toward  real 
space  problems.  Such  strawman  systems  might  include  a  robot 
for  in-space  assembly  ,  or  a  satellite  that  must  correlate  and 
make  decisions  on  multiple  sensor  inputs. 

The  following  architectural  tasks  aie  highly  mierielaled 
(e.g..  hardware  and  operating  sy  stems  studies),  and  mechanisms 
foi  fiequeni  interchange  of  information  between  gioups  work¬ 
ing  m  tins  area  are  veiy  important.  A  series  of  workshops  might 
he  one  such  mechanism. 

The  tollowing  tasks  have  been  identified  ( 1 1  organization 
studies.  (2)  opeiating  systems  foi  large  hierarchic  space  v 
terns.  (3l  tecoveiy  by  problem  sols  mg.  (-11  t.iult  IoIcimkc 
m  veiy -high-pei  loimance  ptocessotv  (5|  aielutectuie 
development . 

I  udeilymg  faskv  1  2.  aiiJ  3  is  die  need  lode'elop.t  hiei 
aicliic  model  of  complex  distiihuted  tunctions  ;n  ASM  space 
cull. and  models  of  the  unci  faces  between  spaccculi  subsys¬ 
tems.  Computing  in  each  spacecraft  subsystem  gi'neiutC'  a 
"viitu.il”  digital  intei lace  between  the  subsystem  and  the 
spaceman  system.  Models  of  these  lnteifaces  should  include 
genei.dized  fault  monitoring  and  tecovery  tunctions  at  each 
level  of  the  hierarchy.  Such  models  may  lead  to  insights  on 
how  to  stiuciuie  these  mieitaccs  to  improve  soltwaie  reliabil¬ 
ity  .  and  fault  recoveiy  .  as  well  as  simplified  commanding  and 
system  integration 

1.  Organization  studies,  lhese  studies  will  include  postu 
hiring  fault-tolerant  distiihuted.  and  hierarchical  compute! 
aiclutccturcs  along  with  communication  formats,  and  soi  l  w  are 
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executive  structures  tliat  are  applicable.  The  first  goal  ot'  this 
component  is  to  perform  tradeoffs  and  pinpoint  the  relative 
capabilities  and  limitations  of  the  postulated  architectures 
with  respect  to  spacecraft  performance  and  fault  tolerance. 
The  second  goal  is  to  develop  specific  fault-tolerance  tech¬ 
niques  for  use  in  these  types  of  systems.  Among  the  fault- 
tolerance  questions  to  be  addressed  are: 

( 1 )  How  can  reliable  clocking  and  synchronization  be 
carried  out  between  the  multiple  processors'? 

(2)  How  can  embedded  processors  with  their  numerous 
input /output  pins  be  spared? 

(3)  How  can  nonhomogeneous  specialized  processors  be 
handled,  especially  when  fault -tolerant  architectures 
are  biased  towards  a  homogeneous  pool  of  processors? 

(4)  How  is  executive  software  organized  to  support  re¬ 
covery.  rollback,  and  diagnosis? 

(5)  C  an  the  system  be  designed  to  tolerate  software  errors 
through  fault-containment? 

(6)  How  does  one  design  virtual  interfaces  that  partition 
software  between  various  computer  modules? 

(7)  How  is  redundancy  distributed.’  What  fault  detection 
is  provided  at  the  various  sensor/actuator  levels  within 
the  computer,  subsystem,  and  system  levels?  What 
are  the  levels  of  sparing  employed  on  chips,  between 
chips,  and  between  subsystems? 

(X)  How  well  can  fault -tolerance  features  be  made  trans¬ 
parent  to  the  user'’ 

2.  Operating  systems  for  large  hierarchic  space  systems. 
Tins  research  is  directed  at  developing  operating  system  con¬ 
cepts  best  suited  to  complex  distributed  systems,  issues  to  be 
addressed  are. 

( 1  )  Hierarchical  partitioning  of  executive  functions 
global/local. 

(2)  It  feet  of  alternative  executive  structures  on  applica¬ 
tion  software  reliability,  testability,  and  fault- 
containment. 

(?)  Interaction  of  executive  with  hardware  and  software 
fault-tolerance  mechanisms. 

(4)  Provability  of  correctness  of  the  executive. 

( ? )  Robustness  the  ability  of  the  operating  system  to 
survive  errors  in  applications  software. 

3  Recovery  by  problem  solving.  Many  of  the  techniques  of 
artificial  intelligence  and  problem  solving  may  be  applicable  in 
dealing  with  unanticipated  fault  conditions,  or  with  operator 
errors  This  task  is  intended  to  develop  heuristic  techniques  to 


deal  with  this  class  of  unexpected  faults  and  possibly 
some  errors. 

4.  Fault-tolerant  high-performance  processors.  This  area 
includes  the  processors  that  will  be  or  are  being  developed 
(e.g.,  signal  processors).  Techniques  to  achieve  fault  detection 
and  recovery,  and  also  to  integrate  such  systems  in  ASM  satel¬ 
lites,  require  investigation.  This  is  especially  true  because  many 
of  these  systems  will  probably  not  work  without  embedded 
fault  tolerance  due  to  a  high  transient  error  rate  brought  on  by 
enormous  complexity. 

5.  Architecture  development.  To  use  ASM  in  a  satellite, 
the  supporting  technology  must  he  in  place.  Project  offices 
are  usually  in  no  position  to  accept  the  delay  and  risk  of 
developing  new  technology.  Thus,  this  research  progiam 
should  develop  one  or  more  fault-tolerant  computer  system 
architectures  to  at  least  the  breadboard  stage.  Fault-tolerant 
architectures  are  sufficiently  complex  that  it  is  necessary  to 
build  and  test  them  to  understand  their  behavior.  It  is  expected 
that  the  selection  and  design  of  these  architectures  would  be 
outgrowths  of  current  architecture  developments  (Software 
Implemented  Fault  Tolerance.  Fault-Tolerant  Multiprocessor. 
Fault-Tolerant  Spaceborne  Computer,  and  Building  Block 
Fault-Tolerant  Computer),  which  would  be  heavily  influenced 
by  the  organization  studies  above. 

C.  Software  Fault  Tolerance 

This  research  area  is  concerned  with  developing  reliable 
software  for  distributed  computer  systems  for  ASM  space¬ 
craft.  It  includes  three  areas  of  study:  (I )  system  partitioning 
and  interface  definition  to  improve  software  reliability, 
(2)  self-checking  flight  software,  and  (3)  fault-tolerant 
software. 

1.  Partitioning  and  interface  definition.  This  task  is  tightly 
coupled  with  the  architecture  studies.  The  partitioning  of 
functions  within  a  distributed  system  and  the  virtual  inter¬ 
faces  between  subsystems  have  a  very  large  impact  on  the 
complexity  and  reliability  of  applications  software.  The  goal 
of  this  research  is  to  study  tradeoffs  between  alternate  parti¬ 
tioning  and  interface  (command  and  data)  definitions  and  their 
impacts  on  software  complexity  and  reliability.  (Such  issues  as 
the  degree  of  system  vs  local  control  of  a  subsystem,  timing 
requirements  on  commands,  acceptable  communications 
delays,  scheduling  strategy,  and  internal  software  structure, 
are  involved  in  these  studies.) 

2.  Self-checking  flight  software.  One  goal  of  this  task  is  to 
develop  methodologies  for  detecting  faults  in  applications 
software  as  it  is  performing  its  normal  operations  This  in¬ 
cludes  the  inclusion  of  acceptance  tests  in  the  flight  programs 
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and  a  variety  of  other  software  fault  detection  mechanisms.  A 
second  goal  of  tilts  task  is  to  develop  verification  and  valida¬ 
tion  techniques,  to  prove  the  effectiveness  of  this  self-checking 
code. 

3.  Fault-Tolerant  software.  This  task  is  intended  to 
develop  techniques  for  developing  software  that  operates  in 
the  presence  of  programming  errors.  This  is  a  difficult  area  that 
involves  the  use  of  software  fault  detection  and  the  execution 
of  redundant  code  to  recover  from  design  faults. 

D.  Modeling  and  Analysis 

In  the  development  of  advanced  ASM  spacecraft  systems,  it 
is  necessary  to  develop  experimental  testing  techniques  to 
verify  the  effectiveness  of  the  built-in  fault-tolerance  mecha¬ 
nisms.  Analytic  statistical  models  that  use  these  experimental 
results  and  component  failure  rates  are  then  required  to  pre¬ 
dict  the  leliability  and  performability  of  the  ASM  spacecraft 
as  a  function  of  time.  This  type  of  modeling  is  essentia)  to 
determine  if  a  given  spacecraft  design  will  meet  its  objectives, 
or  to  perform  tradeoffs  between  competing  design  approaches. 

A  second  class  of  tools  needed  in  ASM  development  are 
functional  models  and  design  languages  that  can  facilitate 
design  and  verification  of  ASM  systems.  Such  tools  could 
provide  the  capability  of  specifying  and  simulating  operations 
of  proposed  systems,  and  allow  changes  and  improvements 
before  a  design  is  locked  into  hardware.  A  second  important 
use  of  design  languages  and  functional  models  is  to  provide  a 
basis  for  formal  verification  of  a  design  bel'oie  launch,  and 
validation  of  command  sequences  to  an  orbiting  ASM 
spacecraft . 

The  modeling  and  analysis  area  is  broken  into  three  compo¬ 
nents  (I)  experimental  testing.  (2)  statistical  modeling,  and 
(3)  functional  description,  modeling,  and  verification. 

1.  Experimental  testing.  Spacecraft  testing,  already  a  dif¬ 
ficult  problem,  will  become  considerably  more  complex  with 
the  introduction  of  ASM  A  significant  pioblem  is  how  to 
test  these  functions  that  arc  dedicated  to  autonomous  mainte¬ 
nance.  The  goal  of  this  component  is  to  acquire  a  deeper 
understanding  of  testing  problems  peculiar  to  ASM,  and 
develop  test  generation  and  test  applications  methods  for 
solving  these  piohlems.  Among  the  problems  to  he  considered 
that  complicate  leslmg  arc:  (I)  testing  at  many  levels  in  a 
hierarchy.  (2)  the  possibility  of  many  combinations  of  input 
events  and  many  unanticipated  faults.  (3)  the  need  to  test  in 
an  artificial  environment.  (4)  wear-out  phenomena,  and 
(5)  the  development  of  specific  tests  required  by  statistical 
reliability  models. 


2.  Statistical  modeling.  Probabilistic  models  of  ASM  space¬ 
craft  are  needed  to  assess  the  probabilities  of  performing  at 
various  levels,  ranging  from  full  performance  to  failure,  over 
the  projected  life  of  the  spacecraft.  Such  models  are  being 
developed,  but  have  yet  to  be  extended  to  complex,  hetero¬ 
genous  spacecraft  systems.  The  goal  of  this  component  is  to 
extend  current  methods,  developed  primarily  for  computer 
applications,  to  accommodate  additional  complexities  in 
large,  heterogeneous  spacecraft  systems.  A  considerable 
advancement  is  required  over  existing  models  to  deal  with  the 
complexity  resulting  front  dependent  subsystem  failures,  and 
the  models  must  carefully  relate  to  testing  results  as  input 
parameters.  Special  emphasis  must  be  placed  on  modeling  and 
analysis  of  transient  faults,  since  transients  are  expected  to  be 
a  major  problem  of  VLSI  technology. 

3.  Functional  description,  modeling,  and  verification. 

Spacecraft  systems  are  complex,  multifunctional  real-time  sys¬ 
tems  with  many  different  types  of  physical  subsystems. 
Although  functional  models  may  exist  for  many  subsystems, 
functional  descriptions  at  the  spacecraft  level  are  typically 
informal  and  incomplete  With  the  additional  complexities  of 
VLSI  and  autonomous  maintenance,  informal  design  methods, 
particularly  at  the  system  level,  may  no  longer  produce  the 
desired  results  (witness  the  evolution  of  computer  operating 
system  design  methods). 

One  goal  of  this  component  is  to  investigaie  whether 
design  languages,  such  as  those  being  used  in  the  context  of 
computer  and  computer-based  systems,  can  be  usefully  ex¬ 
tended  to  facilitate  spacecraft  design.  Of  particular  relevance 
are  languages  that  call  for  timeliness,  fault  tolerance,  distri¬ 
buted  resources,  and  concurrent  (parallel )  execution  of  tasks. 

A  second  related  goal  is  to  develop  uniform  functional 
models  (abstract  representations)  of  autonomously  maintained 
spacecraft.  The  models  sought  are  hierarchical  models  that 
relate  high-level  functional  behavior  of  the  total  system  to 
lower-level  subsystem  functions  and  interactions,  both  during 
normal  operation  and  in  various  modes  of  fault  recovery  or  of 
degraded  operation.  This  type  of  model  can  facilitate  the 
design  process  and  may.  in  the  future,  lead  to  design  automa¬ 
tion  tools  for  spacecraft  design.  Functional  models  might  also 
he  used  to  formally  verify  the  system. 

With  the  increase  in  logical  complexity  required  for  advanced 
ASM  spacecraft,  model-based  evaluation  and  testing  may  not 
suffice  to  provide  the  desired  confidence  in  the  system.  The 
third  goal  is  to  investigate  the  possibility  of  extending  formal 
verification  methods  (such  as  those  being  developed  for  pro¬ 
grams.  operating  systems,  and  at  least  one  avionics  processor) 
so  as  to  apply  to  formal  descriptions  of  spacecraft. 
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The  areas  of  specification  language,  formal  functional 
models,  and  formal  verification  techniques  are  intimately 
related,  and  are  thus  grouped  into  one  component  in  this 
plan.  This  represents  long-term,  high-risk  research,  but  the 
payoff  can  he  enormous 

E.  Sup[>orting  Development 

Two  supporting  developments  have  been  suggested  by  the 
research  group.  The  first,  of  immediate  urgency,  is  ASM  data 
base  development  The  second  is  development  of  a  spacecraft 
laboratory  for  ASM  integration  patterned  after  a  similar 
development  within  NASA. 

1.  Data  Base  Development.  A  comprehensive  data  base 
should  be  established  for  ASM  development.  It  should  serve 
as  a  repository  of  two  types  of  data. 

Tire  first  is  statistical  data  required  to  determine  values  of 
parameters  for  reliability  and  performance  models.  Currently 
used  data  is  often  incomplete  and  inaccurate.  Data  sought 
should  include  piecepart  failure  data  (particularly  transient 
failures),  data  on  VLSI  failure  mechanisms,  and  data  on  sub¬ 


system  failures,  system  failures,  and  that  on  the  environment 
gathered  from  past  missions. 

The  second  type  of  data  is  information  on  existing  (perhaps 
generic)  spacecraft  systems  and  subsystems,  and  information 
on  redundancy  and  ASM  techniques  already  being  used  on 
spacecraft.  There  is  a  significant  problem  of  technology  trans¬ 
fer  between  spacecraft  designers  and  researchers.  This  type  of 
data  base  would  provide  a  multidiscipline  exchange  that  may 
be  indispensable  in  advancing  the  state  of  the  art  in  ASM. 

2.  Spacecraft  Laboratory.  This  is  a  much  more  ambitious 
development.  It  would  consist  of  a  computing  facility  for  ASM 
spacecraft  integration  (analogous  to  NASA’s  Airlab  for  avion¬ 
ics  systems).  This  is  envisioned  as  a  facility  where  spacecraft 
simulations  would  be  provided.  New  hardware/software  sub¬ 
systems  could  be  integrated  and  tested  using  the  system,  and 
new  system  designs  could  be  developed  and  simulated.  Such  a 
facility  would  be  used  for  experimental  testing  of  prototype 
spacecraft  systems,  h  would  be  national  in  scope  and  provide 
both  access  and  a  focus  for  information  exchange  between 
manufacturers  and  researchers. 
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Conclusions  and  Recommendation 


ASM  is,  a  logical,  evolutionary  change  to  the  Air  Force's 
concept  of  space  system  operations  that  results  in  the  transfer 
of  functions  from  the  ground  segment  to  the  space  segment . 
With  ASM.  the  role  of  the  ground  segment  becomes  one  of 
supervisory  control  and  operations  management,  rather  than 
detailed  control  of  operations.  Experience  has  shown  that, 
generally,  spacecraft  have  enough  spares  to  meet  mission  life¬ 
time  requirements,  so  additional  redundant  parts  are  not 
necessarily  needed  for  ASM. 

In  the  opinion  of  tire  study  participants,  the  present  system 
and  current  spacecraft  operate  quite  well  in  that  mission  objec¬ 
tives  and  user  data  needs  are  satisfied.  The  present  space  seg¬ 
ment.  however,  was  designed  to  operate  with  man  and  his 
ground  control  function  as  an  integral  element.  Successful 
space  segment  operation  currently  requires  closure  through  the 
ground  segment  both  before  jnd  alter  the  occurrence  of  faults. 
ASM  will  remove  tins  requirement  (font  tire  day-to-day  activ¬ 
ities  of  space  segment  operations. 


I.  Conclusions 

Tire  following  conclusions  are  those  of  the  study  group 
participants  and  result  from  analysis  of  the  material  developed 
during  this  study . 


1 .  ASM  would  reduce  the  vulnerability  problem.  There  is  a 
need  to  decrease  space  segment  dependence  on  the  ground 
segment  because  the  ground  segment  is  vulnerable  to  both 
hostile  action  and  operator  error.  By  eliminating  dependence 
on  the  ground  segment  for  fan1!  detection,  isolation,  and 
recovery  management,  and  for  routine  operations  functions 
such  as  power  management  and  ephemeris  updating,  space 
system  vulnerability  will  be  significantly  reduced. 

2.  The  ASM  capability  need  not  impose  operational  con¬ 
straints  on  the  system  user.  If  anything,  the  user  should  per¬ 
ceive  a  more  responsive  spacecraft  with  ASM  present  New 
procedures  for  user  system  operations  and  data  retrieval 
should  not  be  required.  Data  outage  resulting  from  most 
internal  faults  would  be  reduced  front  hours  to  second'., 
making  the  ASM  capability  virtually  transparent  to  the  spjee 
segment  data  user 

3.  ASM  would  require  a  change  in  the  conduct  of  opera 
tions  and  control.  Tire  role  of  the  ground  segment  in  system 
operations  must  be  redefined.  Detailed  control  of  routine 
operations  and  maintenance  functions  would  be  assumed  b> 
the  space  segment,  with  supervisory  ground  control  Supervi¬ 
sory  control  would  be  maintained  by  an  audit  trail  capabilus 
that  would  provide  nomeal-time  (up  to  6  months)  visibility 
into  maintenance  actions,  and  by  the  capability  tor  ground 
segment  override  of  space  segment  autonomous  actions 
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4.  ASM  would  add  complexity  to  the  spacecraft  design; 
therefore,  new  methods  for  specifying,  testing,  and  validating 
ASM-augmented  spacecraft  are  needed.  Concepts  for  specify¬ 
ing.  testing,  and  validating  ground-based,  fault-tolerant  pro¬ 
cessing  systems  have  recently  been  developed.  Interaction 
between  computet  and  spacecraft  technologists  during  this 
study  has  shown  these  concepts  to  be  applicable  to  ASM  New 
methodologies  for  design  and  analysis  are  required  to  address 
such  issues  as  fault  coverage  and  recovery  latency  .  measures  «>1 
etfevtiveness.  risk  assessments,  and  proof-of-corieciness. 

5.  A  more  effective  means  of  transferring  technology  from 
research  to  applications  programs  would  be  required.  The  ASM 

study  has  served  as  a  forum  for  the  exchange  ot  technology 
between  researchers  and  application  specialists.  A  continuation 
of  information  exchanges  between  these  two  communities  will 
increase  the  level  of  aw  areness  of  both  the  technological  prob¬ 
lems  and  their  potential  solutions.  As  noted  above  in  item  4. 
the  collective  experience  of  fault-tolerant  data  processing  sys¬ 
tem  specialists  can  serve  as  a  surrogate  for  guiding  the  evolu¬ 
tion  of  new  spacecraft  methods  and  new  technologies  required 
to  satisfy  space  segment  environmental  constraints. 

6.  New  technology  developments  would  be  required.  Two 

specific  technological  developments  were  identified : 

(1)  A  highly  reliable  fault-tolerant  computing  capability 
with  nonvolatile  back-up  memory  to  enable  autono¬ 
mous  maintenance. 

(2)  An  autonomous  navigation  capability  to  enable  inde¬ 
pendence  of  routine  ground  operations. 

The  fault-tolerant  computing  system  is  expected  to  have 
complete  authority  over  spacecraft  resources  employed  duiing 
reconfiguration  by  using  hierarchical  recovery  management 
algorithms,  diagnostic  test  procedures,  fault-trail  reporting 
mechanisms,  and  normal  spacecraft  operations.  This  authority 
must  manage  contention  for  system  resources  and  manage 
subsystem  interdependencies  arising  during  anomolous  opera¬ 
tions  The  conceptual  design  requirements  for  60-day/6-month 
autonomy  necessitates  moving  the  navigation  function  from 
the  ground  to  the  spacecraft. 

7  A  strong  corporate  commitment  to  ASM  by  the  Air 
Force  would  be  required  to  make  ASM  successful.  The  imple¬ 
mentation  of  ASM  would  be  a  phased  program,  with  the 
spacecraft  Heel  evolving  from  non  ASM  to  ASM  spacecraft 
over  a  period  ot  several  years.  The  spacecraft  would  not 


instantly  become  totally  autonomous  The  pace  of  ASM 
development  and  implementation  would  depend  upon  the 
resources,  technology,  and  chosen  program  applications  that 
are  provided.  To  plan  the  implementation  of  ASM  and  coordi¬ 
nate  the  actions  ot  the  System  Program  Offices  and  the 
ground  segment,  a  strong,  long-term  corporate  commitment 
would  be  needed  This  would  insure  successful  integration  of 
ASM  into  the  An  Force's  space  system 

K.  Confidence  in  ASM  must  be  instilled  by  creation  of  a 
systematic  modeling,  analysis,  and  demonstration  program. 
Total  confidence  in  ASM  will  result  on|\  alter  operations  are 
proven  to  be  predictable  and  understandable  llowevei. 
proof-ot -concept  demonstrations  ot  such  individual  ASM 
capabilities  as  batten  reconditioning,  autonomous  recovery 
trom  bus  undervoltage  conditions,  and  autonomous  computet 
sell -diagnoses,  will  help  provide  early  confidence  in  ASM. 
Confidence  will  be  further  established  during  the  transition 
phase  when  quantitative  figures  ot  merit  tor  ASM  and  non- 
ASM  strategies  can  be  developed  within  the  (light 
environment . 

9.  ASM  is  a  viable  concept  ASM  is  the  technological 
infusion  of  ground-based  functions  into  long-lived,  highly- 
rehahle  spacecraft.  These  functions  are  well  understood  and 
operating  successfully  on  the  ground  now.  Precepts  borrowed 
from  fault-tolerant  computing  will  provide  guidance  for  eval¬ 
uation  of  lault-detection.  isolation,  and  recovery  techniques 
appropriate  to  the  space  environment.  Othei  studies  are  in 
progress  that  will  provide  insight  into  the  solution  of  the 
autonomous  navigation  problem,  and  no  other  technology 
gaps  have  been  identified.  TIius.  ASM  is  workable  and.  given 
the  urgency  of  the  present  situation,  it  should  be  started  now  . 

II.  Recommendation 

The  study  group  recognizes  the  need  for  ASM.  and  has 
found  the  technology  available  in  today's  spacecraft  systems 
to  he  a  good  foundation  from  which  to  proceed  to  ASM 
The  plan  presented  is  practicable .  it  aims  at  a  series  of  prudent . 
gradually  expanding  (from  subsystem  to  system  level)  capabil¬ 
ity  demonstrations.  The  study  group  therefore  recommends 
that  the  Air  Force  proceed  with  the  technology  development 
and  research  programs  as  outlined  in  the  Implementation 
Plan  and  Research  Agenda.  These  programs  would  provide 
the  earliest  possible  demonstration  of  ASM  as  a  valid  system 
level  capability,  and  lay  the  research-oriented  gtoundwotk  for 
the  “second  genetation"  ASM  of  the  lc>qQs 
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